Even with significant structure changes at some point you have to move the VFP data into SQL tables. My approach, since I was most familiar with manipulating data in VFP was to do my changes there, creating prgs that work on a copy of of my VFP data, doing ALTER TABLE commands to add fields, copy data, transform data, allow null, generate integer keys etc.



The I pointed Full Convert at that and it moved it to SQL without a hitch.



And if I found something I didn't like I could tweak the prg, tweak the Full convert project, then blow away the SQL database, recreate it from DDT and rerun the process.



Suppose I could have done it with remote views but that turned out to be a lot more work.

Now - that's a good idea (restructuring tables in VFP - then using Full Convert to move.) Hadn't thought of that.



Thanks again!!!



HB

Charles

playing with the trial version of FullConvert, I'm unable to automatically convert VFP autoinc fields as SQL int identity, nor to convert PK.

Is it a limitation in the trial version? do you really convert all  referential integrity with this tool?

All my VFP stuff used GUID pks and I was originally drawn to Full Convert because unlike the "upsizer" it would let me map my GUIDs to UIDs. I never used autoinc integers in VFP databases.



Most of my VFP -> conversion was done for other peoples apps as I started developing VFP apps exclusively against SQL starting about 2002.



I usually found that RI ( especially straight VFP RI without Steve Sawyer's brilliant mod ) wasn't something I wanted to even think about converting so I just moved the table data and set up the RI triggers where appropriate in SQL itself after the data was moved.



When on the Table Setting screen I would only check Recreate Data ( having already created the structure I wanted with DDT ) and then check Skip Indexes and Skip Constraints.



I found it was better to move the data from VFP to SQL without indexes or RI or defaults - ie. data only - no metadata - and then set things up in sql the way I wanted it. I don't trust any "automatic" conversion of that kind of stuff as I always assumed ( perhaps incorrectly ) that the VFP implementation of some of that stuff may have been done to look like SQL it really was different ( RI being a good example )



Full Convert's primary utility for me was in mapping the fields and doing the actual data transfer and storing those setting in projects so they were reproducable and tweakable. I found the VFPOLEDB driver flakey or I would have done it from the SQL side with DDT / SSIS.

Thank you for that explanation, Charles.

New upsizing wizard allows us to create clustered indexes on PK, and migrate VFP RI triggers in SQL constraints. Of course, it's not a magic tool, and I never trust it, and always set the final conversion in SSMS and DDT.

Since VFP6, I use RI with no failure or problem. Moving apps in VFP8, I used autoinc PK.

We have different experiences with Fox and SQL, so we can learn each from others.