There is a multitude of possibilities of SQL Server & VFP. Here are a few.
-Business rules (middle tier).
-Ability to extract a data set to a local cursor and use VFP to further manipulate.
-VFP strong command set.
-Ability to have a local remote application capability using VFP Dbf's that
mirrors the functionality in the main site's system.
-The OOPs in VFP is still superior to VB and creates a great RAD tool.
-Utilize your existing VFP knowledge.
-Importing and exporting a variety of file formats.
==================================
>>>>> Like you, I really want it now, but I'll wait if it means getting a really solid product.
>>>>
>>>>That's precisely why I asked. I'm looking at migrating my data warehouse backend environment from FPW2.6 to SQL Server, and from all I've heard about the improvements in 7.0, I think I'd rather wait on it too if I don't risk hitting the 2gb limit in Fox before they get it out.
>>>
>>>Which would probably mean that you would migrate to VB also. If you are not going to stay with the DB backend why stay with VFP?
>>
>>Whoa.... you don't consider SQL Server a DB backend??? I would keep my backend in Fox if I didnt have to worry about maxing out table size with all the transient data I push through and if it provided better security. And as far as using VB, yes I've been lifted out of my Fox-Only atitude and I have to come to realize a good developer will use the right tool for the job. Now since my jobs that need handled are primarily data intensive, I dont think I'll be implementing a VB front-end any time soon.
>
>Of course it is! My question was, albeit poorly phrased, If you going with SQL Server as the backend (through ODBC, I assume) why use VFP? In VB you would have the Object Browser that everyone on the UT is drooling over, you would have Intellisense and, you can always do cut&paste inheritance! :-)