>I understand there's not much I can do, but I still think the answer to my question is YES, I am enjoying a product that's so damn impressive in performance, ease-of-use etc. that when moving to another language, whilst still being expected to produce fine DB apps, I find myself thinking, why? What are our customers going to benefit the most from?
>
>It all goes back to the work-hard now, lay-back later which at the end of the day only suits the developers, what about the customers who are going to have to suffer with a performance hit on their app, and longer, initial development times?
>
>Kev
>


Well, I agree. There *are* reasons to move from a one tier app with a native data engine, to a client-server app; or an n-tier app using .net; or an n-tier app using ASP. But there are also costs, and one needs to be quite sure that the benefits outweigh the costs.

For instance, I just worked on an upgrade of an app from native VFP data and native access to client/server using SQL Server. It runs much more slowly. BUT, in this case, the client failed an audit because the data wasn't secure enough. So, the benefit of added security outweighed the cost.

In another case, I worked on an app that required access from various mobile vans using satellite-internet connections to laptops. They'd been using a data replication program for years, but now, they found, they needed real-time synching of data across multiple mobile sites. Well, an n-tier browser driven solution worked less quickly, but met a pressing need.

But, in another case, I worked on an app upgrade that was undertaken because "the parent company wants to go n-tier...." The only benefit was satisfying a vice-president who's brother in law told him over Thanksgiving that "the web is the future" and seemed shocked that they had any in-house apps. The cost was a much slower app.





>>Hey Kevin. As Jon mentioned, VFP is simply quicker for database access than anything else (at least that I have used). So, to some degree, there's not much you can do.
>>
>>Having said that, the whole approach to data in .NET (or VB-classic or C++) is so different that in VFP, that you may need to re-think your approaches. VB is slower processing data than VFP under just about any circumstances, but it's at its worst when you "think-VFP" but "Code-VB."
>>
>>For instance, I frequently grab a whole lot of data in VFP (frequently a whole table) and scan through it, taking various actions. Scanning through an ADO recordset is sooooo much slower than scanning through a VFP table or cursor, with large recordsets, that everything will grind to a halt. However, if you step back and consider off-loading some of the scan-processing to the initial SQL query, you could gain back some of the speed....
>>
>>This is just one example, and I could provide lots of others. While the various VFP/VB translation charts that I have seen have helped ease the way to new syntax rules for legions of VFP developers, I fear that thinking about language comparisons word-by-word misses an important part of switching to a new language: knowing its strengths and weaknesses.
>>
>>So, while some loss of performance is inevitable, be careful not to make it even worse by "thinking VFP" while coding in a different language.
>>
>>>>>Like I said, I can understand WHY it has to be this way, but I do feel cheated having being made available to some brilliant DB commands in fox, only to have to be brought back down to reality with a different product.
>>>>
>>>>Kevin,
>>>>
>>>>VFP has a native database engine, VB does not. Simple as that. So it's not truly an apples-to-apples comparison.
>>>
>>>Yes, I understand that, and if that's the case, maybe Visual Studio .Net shouldnt' be marked as being brilliant for DB apps, when it clearly isn't in terms of performance. I know it will improve over time, but never to the standard VFPers are used to.
>>>
>>>>
>>>>Just out of curiosity, have you tried the same operations in VB.NET using the ODBC driver instead of the VFP OLEDB provider? It might perform quicker.
>>>
>>>No, I haven't tried it, I was under the impression the OLE DB provider is quicker.
>>>
>>>Kev