Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Invalid Seek Offset - reproducible
Message
 
 
À
23/07/2006 05:42:39
Thomas Ganss (En ligne)
Main Trend
Frankfurt, Allemagne
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP
Database:
Visual FoxPro
Divers
Thread ID:
01137918
Message ID:
01138925
Vues:
22
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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform