Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
More on candidate key
Message
De
28/04/2003 11:37:35
 
 
À
27/04/2003 01:34:41
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00781792
Message ID:
00782273
Vues:
13
>The findings are still not perfect. I added a SYS(1104) command just before the unlock in order to assure that the data is written to disk. But, I suspect this command doesn't work exactly as it is suppose to be as I still have duplicates. Those duplicates are clicks issued by the same user at the same time. So, the locking mechanism seems to be ok but once the other app gets the lock, the LOCATE doesn't see the new added record, thus it add a new one with the same values.


1st) i have only Vfp6. what does sys(1104) do (flush)?
2nd) how can 1 user issue a click at exactly the same time. are we talking about a double click with ms inbetween?
3rd) i have looked at you functions again, and i think it has a flaw, but some else has to give us some info on this. here it is: in your following loop
>DO WHILE (NOT RLOCK()) AND (INKEY(0.1)=0) AND lnCompteur<=25
you are actualy issuing 25 times RLock(). now here is the 65 mil$ question: if you already have a record locked and you issue a new RLock(), doe vfp 1st unlock and then places the new lock? now i know we are talking about an awfull small amount of time, but it might just be enough for the looking to mess up.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform