basversion

robv

Hello

I have a weird situation (version3). Have looked in the forum for an explanation or clue but no luck.

I have been importing data into a test db. One of my tables (mySQL) when exported to csv using an 3rd party ODBC query tool results in errors in the resultingtext file. I have identified that the lines in the CSV with errors results from records in the table that have a BASVERSION = 1. 95% of the fields in these error row are {nulls}.

But the strange thing is that there are surrounding records that are BASVERSION=2 and they are fine. It is just the BASVERSION=1 records that have the issues. I have identified that the export errors are due to the ODBC tool not handling {nulls} in the rows.

So the table could look like this.

ID - BASVERSION - COL1 - COL2
4 2 XYZ1 ABC1
6 1 {null} {null} < --- error occurs
8 2 XYZ2 ABC2
11 1 {null} {null} < --- error occurs
16 2 XYZ 3 ABC3

So the issue moves to the {null} fields and why they are there. The clue for me is simply - what is the basversion column for? What populates it? I have thought that maybe it is being populated by a different version of the application (I am incrementing versions) but the id numbers are sequently growing like in the example, so I would have expected the first set to be basversion= 1 and the remainder basversion=2 if it was a version thing.

Also the rules for the object have not changed in these different versions, so why would the basversion = 1 be populating {nulls}s and the next version not? Nothing has changed in these rules.

Hope some light can be shed on this.

aware_support

If you are trying to import CSV files created from 3rd party tools into Aware IM you need to remove the column with BASVERSION as this is an internal column and should never be used when importing CSV files into Aware IM

robv

I only use AwareIm to import data, no third party tools to do this. We have just used a 3rd paerty tool to query / report on the data in one table.

The issue I need clarity on, is that the table's records look different when they have BASVERSION=1 record to when they are BASVERSION=2 records.

BASVERSION=1 produces mostly nulls in the columns, whereas in BASVERSION=2 records, the columns are populated with spaces (which is correct as this is what our rules do).

There have been no rule changes that account for this data changing.

So the question is: what is BASVERSION=1 doing differently to BASVERSION=2? I do not know when how or why AwareIm writes to this column so I cannot track the reason for this anomaly.

If, for example, BASVERSION=1 indicates an import process, whereas BASVERSION=2 indicates normal transaction then I could identify that the error arises with the imprt process.

I just need to establish why these nulls are appearing in the table.

Thanks.

aware_support

Rob, I don't understand this. If you import data into Aware IM as CSV file then your CSV file must have a proper format that Aware IM understands. This format PRECLUDES any usage of the BASVERSION column, because this column is maintained by Aware IM automatically. This is an internal column and indicates the version of the instance of the business object. You do not need to know why this version exists and what it is doing.

We cannot explain why you are having problems if you persevere using this column when you import data. PLEASE DO NOT USE IT.

robv

Sorry if I have not been clear.

In summary then: I am not touching this column BASVERSION. Any importing I do is via the standard Aware IM import menu option. Also my import file is simple. Incidentally, I only discovered that this BASVERSION column exists when trying to establish why my data had problems. It was here I used a third party product to look at the data.

The situation is simply this: One of my tables appear corrupted. It has nulls in most of the fields where the rows are BASVERSION=1. The other rows where BASVERSION=2 do not have this null problem. This worries me cause nothing has changed in this part of the application between different versions.

I think that it is not going to be possible to trace this error down. My only hope is that the conditions under which it occured was totally unique and that it won't happen again.