>>>>>I'm beginning a migration of our application from using VFP tables to using SQL Server. Rewriting the biz objects isn't too difficult since I've got some basic table insert/delete/update code. I've got a lot of report code though that for speed reasons, accesses the VFP tables directly to pull data. How can I minimze the changes to the report code when migrating to SQL Server 2005? Can I create a FoxPro remote view on the fly at the start of each report, that references the SQL tables, then from then on the code thinks it is accessing VFP tables?
>>>>
>>>>Yes you could but wouldn't SPT or ADO (CA) be better?
>>>
>>>Is a remote view to SQL Server data on the same box, about as fast as SPT?
>>>
>>>My fear with SPT is that the SQL synatx is different and more restrictive.
>>>
>>>>VFP reports don't care about actual source as long as they can evaluate expressions (hope you don't mean you used tables in report DE and/or aliased field expressions).
>>>
>>>I have a report object that has all of report code, then when all data retrieved into a single cursor, calls the report. Pretty typical I think.
>>
>>SPTs are faster than RVs in general (not always - fox.wikis.com have some benchmarks).
>>SPT syntax is different? Might be, not sure what you really meant and I rarely use RV:)
>>SPT is more restrictive? To my knowledge it's RV that's more restrictive:)
>
>
>These benchmarks show the SPT and remote views are close for pulling data http://fox.wikis.com/wc.dll?Wiki~Client/ServerTechniquesPerformance
>SPT is different and restrict because I then have to modify my SQL statements from rich VFP SQL to more plain SQL Server SQL (ANSI?) and I am trying to reduce the amount of code changes. Though thinking this through more, in both cases only the initial queries are pulling data directly from the tables, the rest of the code is using cursors. So the code change might not be that big.
>
>Thanks as alway Cetin. This has pointed me in a direction.
>
>I actually lost sleep last night thinking about this conversion processs, because I had forgotten about the report code. I think this will only add 1-2 weeks to the total project.


"SPT is different and restrict because I then have to modify my SQL statements from rich VFP SQL to more plain SQL Server SQL (ANSI?)"
I see your point. As you move in SQL server you'd see actually VFP's SQL is not rich:) ANSI SQL92 is much better and SQL server 2005 additions are cooler. Anyway I understand you should spare time for that later.
PS: You could get SQL from your RV properties and use with SPT and continue with local VFP SQL. In VFP9 I think somewhere I saw 'Create compatible SQL' tool/sample?
Cetin