1- In ODBC interface, the Carried On data is not properly exported. For example while input, if Dia for element # 1 is 6” and dia for element # 2 is not specified i.e. carried on from previous element than dia for element # 2 in the exported “Input_Basic_Element_Data” table is given as 0 instead of 6”.
2- The bends data given in bends table does not correspond to Bends Pointers (BEND_PTR) given in “Input_Basic_Element_Data” table. The same might be the case with other auxiliary data.

Is there any quick fix to these problems?

1) Actually it is exported properly. The CAESAR II input file is actually a difference file. So for example, the diameter is actually stored only on those elements where you typed in a numeric value. (You can see this if you look at the Element List, the values in <font color="#ff0000">red</font> are the values you typed in. The values in gray, are the ones CAESAR II duplicated for you.)

The ODBC export simply sends out the raw data from the file, so the zero is in fact a correct reflection of what is in the input file.

2) I just verified the "bend_pointer" data - it is correct. One thing you have to be aware of is that the bend pointers are assigned increasing numerical values (1, 2, 3, etc), but are assigned to the elements in the order in which you define the bends. So, if you defined the bends as you built the model, walking down the pipe, the bend_pointers should be in "counting" order in the Element_Table. However, if you forgot one, or sometime later went back to the system and added an expansion loop, the bend_pointer values would not necessarily be in numerical order. This doesn't really matter though. If element #50 has a bend_pointer value of 11, then element #50 is assigned the 11th bend, and the bend data is in the 11th slot in the bend array.

There is nothing wrong here. You can get a better understanding of the data structure if you review the section in the Technical Reference Guide on the "Neutral File Interface".

Dear Richard,

Thank you for the reply.

1- I checked it in ver 4.4 where the data was exported in full without zeros for the duplicates and that seemed more meaningful as we could retrieve element data e.g Diameter by referring element no alone. If this is changed intentionally then much of the usefulness of the exported data is lost, as we can’t retrieve the element data by referring the element no.

2- In neutral file we can retrieve the auxiliary data for an element by looking at the particular position in Auxiliary Element Data array, which is governed by the pointer value in Basic Element Data array.
In ODBC the Auxiliary Element Data tables e.g. Input_Bends have the same pointer values as in neutral file, but the pointer values in Input_Basic_Element_Data don’t match with those in Basic Element Data array of the neutral file
So in neutral file, if the pointer valve related to a bend is 10 (which means that the bend data is at 10th position in auxiliary array) then the pointer valve should be 10 in both Input_Basic_Element_Data and Input_Bends tables. This is not actually the case, as Input_Bends table would have a pointer value of 10 while the Input_Basic_Element_Data table would contain pointer values which are apparently generated in random.
Hence it is not possible to retrieve the auxiliary element data by referring the pointer given in Input_Basic_Element_Data table.

I'll have all of this verified. "Did we change this intentionally? No." However, one of the base DLLs that the ODBC export relies on is used also for the PCF import and the ISOGEN export. All three interfaces are tied together, so a change in one can have unexpected affects on another.

1) We just verified that Version 4.40 also put zeroes in the data tables for duplicated data. We can look at having this export facility perform the same duplication, but I can't promise what version that will be released in.

2) We are not seeing this, all the pointers make sense. Please e-mail me a sample MDB file showing this problem.

Thank you Richard.

I sent the sample file by e-mail.

ODBC export was really a nice feature added to Caesar and can be time saving in many situations. I wish this to work.