>>The application handles workorders for a phone company.. For each workorder, they are building a header table (One record) plus a detail table(one record per part/labor item), plus a materials table is generated from the detail table... Add to this, that the main data entry form is layed out using private datasessions that have to be tracked (so that reports can be run off the active form's data).. And you have a royal pain in the A$$..
>
>What do you mean by "datasessions have to be tracked"?
>
>>We tried the app in one site for testing purposes, over a LAN, one of our faster sites, and found people were getting flustered with the speed of the app...
>
>What LAN software? What type of computers (CPU/RAM)?
>
>As far as I understand, the problem is with the data entry form speed. Try to see which part is slow. This is one of the best places to apply divide et impera method. Try to see if the slowness comes from the data processing, objects that take to long to be instantiated, etc.
>
>Vlad

Paul,
Most people will be running using atleast p-100 machines, either accessing over a LAn (All Novell Lans) some over 56k dedicated lines..

My major concern is (Posted in another message, will rephrase) is the system was more a porting of code from FP 2.x to VFP, where we are using a more flat-file storage means for data than a relational design, and have no use of VFP's features (Database container, no buffering, not even using old FP memory variable style screens.. We are reading/writing Directly to the data tables involved)..

See any problems so far?? I certainly DO...

Thanx!

Tony Miller
Vancouver,Wa