Thank you very much for a detailed and helpful input.

>I have a very large app that has the data split between VFP and DB2. This is app designed with VFP data and I am working on making it database independent. I needed to move one table because of the 2gig table limit in VFP. My original idea was to move just the one table but so found of the 100 or so tables it was most effectient to move about 10 tables to the DB2 server and not just the one that needed to move because of the 2gig limit.
>
>The reason for needing the additional tables is I had certain things that are better done in one place: SELECT * FROM PARENT_TABLE_ON_DB2 WHERE KEY IN (SELECT F_KEY FROM CHILD_TABLE_IN_VFP)
>
>I still have cases where I need to do this type query and I have created a function to convert a cursor/table into a long where clause: SELECT * FROM PARENT_TABLE_ON_DB2 WHERE (KEY=val1 OR KEY = val2 or KEY=val3 or KEY=4 or ... )
>
>This kind of statement can get long but it works.
>
>I have also found that using the CursorAdapeter class is very useful in making the transition with mixed data locations, and the enhancement to it in VFP9 could be of use to you.
>
>One thing I had planned on doing was making the changes to the application while using the VFP ODBC driver to point to the VFP Data and when everything was ready I would move the data over to backend and just change the connection to the backend database. I ran in problems because the VFP ODBC has not been update since VFP6 and my data used Autoinc fields. This should not be an issue if your data is all VFP6 and it may be a nice way to take it slow.
>
>
>
>>I was wondering if anybody ever created a project with database split between VFP and SQL Server? How practical it was? Any problems?
>>
>>I want to start converting a very large application from VFP 6 VFP DB to VFP 9 and SQL Server. But I realize the magnitude of the project will be too big to accomplish in reasonable time. So I am thinking about an approach of moving only one table to SQL Server. This is a very big table (of about 300,000 records) that often gives me problems (corruptions). Then, I could move other tables of the application to SQL Server, one step at a time.
>>
>>Any suggestions or warning will be greatly appreciated.
>>
>>Thank you.