>>>>>Well, there are probably tens (if not hundreds) of issues you can address in order to achieve a better performance in VFP. If you're looking only for advice with 56K comunication, I can't help you.
>>>>>
>>>>>If you're looking for general advice, you probably need a good book. There's a list of VFP books here on UT.
>>>>>
>>>>>For any other specific question, I'm sure you'll have very good answers here on UT. But you must specific. :)
>>>>>
>>>>>Very brief:
>>>>>Where I look first when I have to optimize a FP/VFP application: Rushmore. The existance of all important indexes. This is extremely important in order to use Rushmore at full power.
>>>>>Second: the data model. But usually this cannot be changed when you deal with apps that already exist.
>>>>>Third: Analyse the "problem" processes. Almost everytime there's a better way! :) So, I test different versions. Sometimes is not obvious which one is the best for your goals and only the tests will give you the correct input. There are so many factors that influence the performance, so, I believe nobody can be 100% sure which one is the best, etc, etc.
>>>>>
>>>>>Vlad
>>>>>
>>>>>> And is there any input you can offer??
>>>>>>
>>>>>>Thanx!
>>>>>>
>>>>>>Tony Miller
>>>>>>Vancouver,Wa
>>>>
>>>>Paul,
>>>> Sorry I was so short.. The app was about 60% complete by the time I took it over, and it is not the greatest thing I have ever seen... For one thing the database is a mess..
>>>>
>>>>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$$..
>>>>
>>>>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...
>>>>
>>>>Thus, why I was asking about tips to speeding up a VFP 5 app..
>>>>
>>>>Thanx!
>>>>
>>>>Tony Miller
>>>>Vancouver,Wa
>>>
>>>Tony, why do you see the private datasessions as causing problems with the reports? Even if you are using buffering ( which I think you said you weren't) (and which you SHOULD be using) you merely have to make sure that the user either Saves or Undoes (TableUpdate/TableRevert) when they leave a screen. Code can be put in the Deactivate method to do this.
>>>
>>>Barbara
>>
>>Barbara,
>> No, we are literallt writing to the file, not even using the old 2.x memvar trick.. So, if a user decides he doesn't like what he has entered, he has to change it back.. The thing I am going on about is, that forms I had thought and everywhere else that deals with Data sessions didn't really have to track them and pass them around as part of the process (as parameters for a form, or a report)..
>>
>>I am have read a few books on developing in VFP, and looked at a framework or two (Am looking to maybe settle on Visual FoxExpress), but it's hard when the database design is so bad, that you can't use the features of the language that you are working in..
>>.
>>
>>Sorry for the ranting, but with the people I work with, it seems like they either don't get it, or they really don't give a damn..
>>
>>Thanx!
>>
>>Tony Miller
>>Vancouver, Wa
>
>Tony, could you set buffering on in each form? Add an (invisible to the users) tableupdate() command whenever you move the pointer so everything is saved, and pretend it's still the way it was? Shouldn't take much time for each form, and your data would be a LOT safer!
>
>I'm still not sure what your problem is with the reports - Could you explain again?
>
>Also, feel free to rant. We ALL meet with idiot bosses, clients and end-users on occasion.
>
>Barbara

Barbara,
Would love to do buffering, but since I can NOT use a DBC, I don't think this will be possible..

Thanx!

Tony Miller
Vancouver, Wa