John,

>That aside, I did a project about 2 years ago in SQL server using Cursors and Record Oriented processing to migrate data from one database scheme to another, which involved translating and updating primary keys and foreign keys in multiple child tables. I spent a couple of weeks writing the routines which when completed and run on main database took 77 hours to complete.

>I went back, rethought the process and then produced a complete set-oriented approach which when done, took less than 45 minutes to do the same thing. Its my experience, that set oriented will always outperform record-oreiented processing given the horsepower on the server to accomplish it.

As I've been saying before, you'll need to take the right approach for the right problem. Database conversions are ussually SET ORIENTED problems as you talk about SET operations. Esspecially when you talk about doing massive updates RECORD ORIENTED approaches, esspecially in SQL server have massive perormance hits. This is because each and every update you do is a seperate transaction and SQL statment that needs the optimizer to work. In that case, it really does not make sense to approach this from a RECORD ORIENTED approach.

Whenever I do conversions from one database structure to another (And I've done dozens of rather large ones in my carreer) SQL was my friend. However that being said RECORD ORIENTED approaches in VFP do not have so much of a disadvantage compared to SQL, because (Again read the previous article) you have direct access to the internal schema (SEEK) and if you do your locking right (usually not an issue as everything is opened exclusively) and use the right dml, you can combine the two to a very powerfull combination. I find it most cost effective to write the entire conversion process in VFP and upload the result into SQL server as I then have the best of both worlds. If I need to lookup child data for the ocasional individual record, I would use SEEK(), If it is consistent through out the whole set, I'd probably join in the cursors into the SQL Select statments.