Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Invalid Seek Offset - reproducible
Message
 
 
To
23/07/2006 05:42:39
Thomas Ganss (Online)
Main Trend
Frankfurt, Germany
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01137918
Message ID:
01138925
Views:
16
Thomas,

Here is another strange anomality with the process. Here is how the process goes:

LoadNewTrans inserts records into multiple tables, then commits changes, then calls ProcessNewTrans, which does multiple replacements/inserts and commits changes as well.

I found, that if I do this process in this sequence for ~8K records, the LoadNewTrans takes 1h.30 min. and Process New Trans takes > than 4 hours.

If I then re-run Process New Trans, it takes less than 10 minutes.

Well, the difference is that in the first case I insert records into Trans_Employees_Queues table and in the second case these records are already inserted. However, 4 hours and 10 minutes still don't make much sense. I'm thinking of commenting out the call to ProcessNewTrans in LoadNewTrans and see, if I still get the same 4 hours then running two processes independently. Both processes are subclasses of BusinessProcess class, which is based on Session class. In other words, if running them in the LoadNewTrans calls ProcessNewTrans sequence I create two datasessions. If running one, then another, we would not have two separate DS.

>>No, we use transaction only when committing changes. E.g. first we made lots of insertions/replacements in lots of tables in buffering 5 mode and at the end of the process we commit all changes using transaction. Pretty much standard approach.
>
>IF you have a scenario reproducible on different machines with table located and indices recreated(!) on each machine, it might be worth your while to run the same scenario with transactions disabled. At least in vfp6 we had an issue with a setup just like you describe, where the frameworks methods (based heavily on table buffering) were not compatible with transactions. I am not involved with that project anymore and don't have access to the demo code causing the specific error (Chr(0) in many fields) to test against vfp9.
>
>You need to identify the bare bone factors causing the error and transactions, buffering and other table based actions didn't go together at least once in my expirience <g>.
>
>regards
>
>thomas
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