The upsizing wizard has the same feel as View Editor circa vfp 7. I just can't shake the idea that somebody wrote it one afternoon, tested it against two or three things and moved on. And then it hasn't been touched since ( at least the view designer will now handle more than one join :-)

If you are working with SQL 2000 try DTS. The easiest way is to right click the database in enterprise manager ( you don't have to create the table or the structure first, just the database ) and pick Import Data from All tasks.

There are a couple of gotchas there as well - the trickiest one if you have guid(36) keys you want to convert to unique idnetifiers. Then you have to hack the script a little. If you have guid(16) keys you can actually upsize them since uniqueidentifiers are binary16 and they will just read your guid as a binary.

Install the VFP 9 ole db provider before you start - works better than ODBC

Oh, and if you are working in SQL 2005 and can figure out how to get the VFP OLEDB provider to work with SSIS ( the new DTS ) please let me know.



>>>I'm converting an application from using a VFP database to a SQL Server 2005 database. Is the upsizing wizard the recommended way of building the SQL Server data tables and transferring the data? Is there anything that it won't do for me? Apparently I will have to rewrite my triggers. Does the VFP referential integrity code transfer well, or should I redo that in SQL Server?
>>
>>There are a number of gotchas with using the Upsizing Wizard. While it may make a good starting point for relatively simple VFP databases, you may encounter one or more of the following:
>>
>>1) size issues: not only does VFP allow for tables wider than allowed in SQL, the upsizer limits the max width to about a quarter of what is legal in SQL.
>>2) You already know about the trigger issues, but be careful of indexes and SP's that use VFP-specific syntax
>>3) SQL reserved words used as table or field names will have an underline character added
>>4) Be careful of empty date values. These will be translated as "1/1/1900" in SQL. This may or may not be valid in your system.
>>
>>RI code should transfer, with the caveat regarding VFP-specific functions.
>>
>>Just some quick thoughts. I've used it, but nearly always construct either a VFP program or use DTS to transfer production data in the end.
>
>Thanks for the tips. Since posting this, the only way to get the wizard to work was to get it to create the structure and not transfer the data. I will do as you suggest and programmatically transfer the data myself. The upside to do that is I will learn the syntax for connecting to SQL Server.