Catalog refreshes seem to crash after Office 2003 RTM is installed. The crash is located in a routine that relies on the ordinal of a field in a table. I can't reproduce the problem, since I don't have office 2003 (I use openoffice) and with MDAC 2.8, the latest data objects, everything seems to work fine. (Not a single line of code relies on any Office component, I only use 100% pure .NET code)

I'll rewrite the field migration routine to avoid the code that seems to cause a crash. Stay tuned.

I have not had any problems using the version of Office 2003 Final released to MSDN subscriber downloads this week. I downloaded it and installed it yesterday and my LLBLGen refresh catalog works without any issues.

Hope this helps.

Dave

DaveVerwer wrote:

I have not had any problems using the version of Office 2003 Final released to MSDN subscriber downloads this week. I downloaded it and installed it yesterday and my LLBLGen refresh catalog works without any issues.

I also find it weird, however 2 users reported problems (the same problems) and both of them had Office 2003 RTM installed. I thought it would be MDAC 2.8, however it seems that's not it....

If you add a new field to a table, at the end, then do a refresh catalog, does that work? It does here with a catalog and a project that seems to cause trouble on a machine with office 2003 RTM installed. (It seems IList.Insert() fails when the index is equal to the amount of items in the list, which should result in an append according to the .NET docs. )

I tried this for you, added a field to a table, refreshed the catalog and regenerated my code.

No crash.

I have not explicitly installed MDAC 2.8, although Office 2003 may have done it for me.

DaveVerwer wrote:

I tried this for you, added a field to a table, refreshed the catalog and regenerated my code.

No crash.

I have not explicitly installed MDAC 2.8, although Office 2003 may have done it for me.

Thanks for testing, Dave! I'm waiting till KMan is awake and he can try out the patched dll I've send him. Apparently office 2003 isn't the cause of this... it's getting weirder and weirder ... Anyway, I hope the patch will work now, so this one can be closed

It works !!!

After the refresh LLBLgen reported: Entity Fields saleprice tblItems - 23 Entity Fields saleprice tblItems - 24

Counting from 1 in the entity editor the fields are 22 and 23 Edit: Thats 21 and 22 starting from 0 as it should be.

I am going to add a couple other fields to for a test and get the count on them.

Go my 4 hours sleep and ready to go Thanks much Frans!

Ok, I've altered the title a bit, because office 2003 is not the cause of it, sqlserver and its incorrect docs are

What's the cause? When you look at the docs of INFORMATION_SCHEMA.COLUMNS, you'll see a column 'ORDINAL_POSITION'. Now, when you look at the docs of sp_columns, you also will see a column ORDINAL_POSITION. Now, the sp_columns one is simply the index of the column in the table (which is what I need) and the INFORMATION_SCHEMA.COLUMNS one is the colid, and NOT the index, although the docs try to let you believe that.

So I used that INFORMATION_SCHEMA one to get the index of a column in a table and to refer to a column internally. However, and here's the catch: SQLServer does not keep the colid's continuous. This means that when you delete a column at the end, and add 2 new ones, the 2 new ones have an ORDINAL_POSITION of 1 higher than the column you just deleted, that is, in the INFORMATION_SCHEMA.COLUMNS view. When you call sp_columns, they have correct, continous numbers.

Still with me? ok. Here's what I'm gonna do: I'll rework some code in the sqlserver driver which will insert the correct POSITION of a column in the table in the fields, not relying on the ORDINAL_POSITION of INFORMATION_SCHEMA. This way, the ordinal positions are kept correct and stay correct and every code relying on these columns will keep on working.

I don't think I'll manage to fix it all today, so it will be tomorrow (friday) when I'll release the patch. If you get an index out of range exception when refreshing a catalog, you now know what the reason is and that a patch is available shortly.

Frans, Will it be ok that the values do not match for live vs. local develoment databases and the reported 'ORDINAL_POSITION'? That is once you have it fixed?

Kman wrote:

Frans, Will it be ok that the values do not match for live vs. local develoment databases and the reported 'ORDINAL_POSITION'? That is once you have it fixed?

Yes that's ok. With the fixed driver, when you do a refresh everything will be ok. The runtime code will not rely on ordinal position, it uses column names, so you are safe

This is fixed in sqlserver driver 1.0.2003.0917, which will be released on september 18th (thursday).