Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Slow save in VFP9 comparing with VFP8
Message
 
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01015381
Message ID:
01015405
Views:
21
We found a way to reproduce this behavior. The difference is in loading libraries in VFP8 and VFP9.

Here is the exact scenario:

Open VFP8. Edit class. Run the form in VFP9. Saving happens very quick.

Now change the class in VFP9. Run the same form. Saving takes long time.

We repeated these steps few times and this is the pattern we found.

Here is statistics:
* After changing the class in VFP8:
The Save method for Employee_queue_activity_bizobj1 takes 0 sec.
The Save method for Transresolutioncodesbizobj1 takes 0 sec.
The Save method for Transpatientsbizobj1 takes 0 sec.

* =========

* After changing the class in VFP9:
The Save method for Employee_queue_activity_bizobj1 takes 6 sec. 
The Save method for Transresolutioncodesbizobj1 takes 13 sec. 
The Save method for Transpatientsbizobj1 takes 19 sec.
Now, what should we do to fix this problem?
Our classes have Builder and BuilderX properties set, if this makes any difference.

>Hi everybody,
>
>We're using MereMortals framework. We switched to VFP9 few days ago. We have one complicated form with lots of Business objects. When we save data in VFP8, it happens quickly. If we do the same in VFP9, it takes almost a minute to save.
>
>We checked CPDBF() and CPCurrent(1) for every table in the database. They are all 1252. We disabled RI and it didn't make a difference. We're not using STR() in index expression. We do not have index on deleted().
>
>We think the problem lies in Transaction handling, which is different in VFP8 and 9. We open transaction, then save parent BO, then save all the children, then close transaction. Each child is wrapped in its own transaction.
>
>I think I read some threads here with the similar problem. Could you please point me out to them and also suggest, what could be wrong in our situatiuon?
>
>For now we have to revert development back to 8 until we find the root of the problem and fix it. The current speed is unacceptable.
>
>Thanks a lot in advance.
If it's not broken, fix it until it is.


My Blog
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform