>>I'll have to do a search of the MS KB on this, Chris. Hopefully, since we're in 7.0 this will be something that's been fixed.
>
>There will still be the problem with the @@IDENTITY value. It is not a bug, but a feature < g >. And it makes sense... if you ADD a record with an IDENTITY column, and a trigger is fired which ADDs a record in a table with an IDENTITY column, the @@IDENTITY value will be that of the second table. But this may not be a problem in your case.

OK, I see what's going on. Not an issue with the vast majority of the stuff I do. The production tables are all flat. They have to be since data used to calculate the efficiencies are only valid at the time the production created. For example, actual machine RPMs are needed. Machines can and do change, with newer ones replacing older ones. Standard data can and does change as well.

>>The only problem (so far) that I've had is that the VFP upsizing wizard (even in SP 4) wants the compatibility level set no higher than 6.5. So it's been into the Query Analyzer, set the compatibility level, upsize the table, then set it back.
>
>After reading the Client/Server book, I avoided the Upsizing Wizard and used DTS (Data Transformation Services. I have had much better luck with that.

I haven't had time to get into that, but I've been meaning to take a look. Right now, I'm working (except for the testing I'm doing with another system) mostly with a local (to the machine) copy of SQL Server. I really haven't had too much problem with the upsizing wizard except for the compatibility level issue. However, you've given me another reason to get the book.< g >