Good stuff, Paul.

Sounds like you hit and solved lots of performance issues.

Really don't quite understand why moving from parent to child tables was so time-consuming, though. But if you've got it decent now, that's really all that matters.

Cheers,

Jim N

>Hi Jim,
>
>In both cases, fpw 2.6 and vfp 5.0, the app is on the client PC. What was taking time in getting the app going in the 2.6 case was the opening of tables at the beginning of the program. And when the program was up and running with tables open, moving from parent table to child table with records was too slow for my paying client (5-10 min).
>
>In the current vfp 5.0 app with SQL Server, I keep the lookup tables local to the client PC in vfp, with a download option to refresh them when they sign on. So the local lookup tables are VFP. I also use local VFP tables to do any complex calculations. I download just the required amount of info from the server, do the calculations locally, and then write the results to the server. Calculations that used to take 15 min on the server, now take less than 30 seconds including downloading and uploading on a 28.8 connection.
>
>You are right about mitigating factors. The client, a B.C. gov't ministry, is under a directive to use Oracle as the server database. I are doing development in SQL Server, but keeping the server database simple. I'm enforcing the business rules in the VFP application. This will make the eventual migration from SQL Server to Oracle quite simple (I hope), without many changes in the VFP application.
>
>Having vfp as the client and SQL Server (and soon Oracle) has worked very well. The paying client is very happy. I doing the development from a home office using a slow 28.8 connection to the server.
>
>Paul
>
>
>
>>Hi Paul,
>>
>>But you don't tell us if your app. is actually on the remote PC or if it is downloaded from Server for execution.
>>
>>If it is on the remote PC, then I would guess that you could obtain even faster response using native VFP instead of SQL Server. I understand that there may be mitigating factors in your move to SQL Server, but I wouldn't attribute *that* as the reason why your app. "runs very well".
>>
>>Cheers,
>>
>>Jim N
>>
>>>Hi,
>>>
>>>I was in a similar situation with a fpw 2.6 app. We have since gone to vfp as the interface and using ms sql server as the database. Still with the slow phone lines (28.8 modem), the application runs very well.
>>>
>>>If your application talks to views of tables, it is not too big of a job to convert to client server. If, not, it is probably a big rewrite.
>>>
>>>Paul
>>>
>>>
>>>>MyApp was designed to run in a local network. it takes about 2 seconds for loading. Recently, i have a remote user (via modem, 56k,connected at 115,000 bps using compressed data) and it takes aboud twelve minutes for loading. What do you think is the problem?