>Hiya Bill ----
>
>As someone already pointed out, this may be more of a database server issue than a VFP vs SQL Server issue. Seeing as how you have many hundreds of thousands of records and distributed processing going on, I would lean towards SQL Server as the data store.
>
>It also sounds to me like the guy you're working with should back off and allow you to design the queries and normalization of the server database.
>
>>Okay, fine. Now he'd like SQL Server everywhere, citing that it's strategic to MSFT, integrates with MTS, has security, transactions and automatic replication, and 7.0 comes with record locking. He also states that the .DBF is dead, VFP isn't strategic, and any VFP solution is a "one-time" solution that isn't scalable.
>>
>
>He's partly right. SQL Server is becoming *the* universal database for MS (in re: the MS Database Engine). The .DBF is not dead neither is VFP but it is getting harder and harder to suggest using the DBFs as a strategic, enterprise solution.
>
>>1) Performance. I *know* I'll come up with an application significantly faster with VFP against DBF's versus against SQL Server. Anyone with real world experience with this? His solution -- Hardware and denormalization.
>>
>
>Yes. A VFP app with the native database engine *is* faster. But it seems to me that speed is not your only issue here.
>
>>3) Transactions and closeness with MTS -- Most of this application and others they develop is read-only. Transactions aren't an issue. Plus, they're comparing SQL Server with FPW 2.6, not VFP.
>>
>
>Certainly there has to be *some* I/O with the data server? And that could come from a number of different apps, right? Sounds like the data management capabilities of SQL Server are needed.
>
>>5) Replication -- Automatic replication with SQL Server. That's true, but this just isn't for this company. This is a commercial application. He's proposing having everyone somehow dial in, wipe out their data sets and bulk copy down 400 megs or so. I just don't see that happening flawlessly with every customer with SQL Server.
>>
>
>This sounds like a topological nightmare regardless of whether or not VFP or SQL Server is managing the data.
>
>>Things not mentioned -- Data Maintenance (DBA stuff). This is a breeze with VFP, but a bear with SQL Server.
>>
>
>SQL Server 7.0 makes some giant strides in ease-of-use. In fact, I've had some SQL Server DBAs tell me that they fully expect that some applications may not even need to be babysitted by a fulltime DBA.

John, part-time DBA (i.e. consultant) may be more expensive :).