Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Append recs goes overlaped
Message
De
21/01/2002 13:02:29
Cristian Tenea
Aquila Part Prod Com
Ploiesti, Roumanie
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Divers
Thread ID:
00606423
Message ID:
00607864
Vues:
42
>Cristian,
>
>Where are you setting ther Primary Key value for the new Parent record? Perhaps the PK is being reused by the second user.

I think you don't see one of the previous messages, I make a transcript:

All started from a problem like "Update conflict" on new records - and trying to pass this I put a tableupdate(.T.,.T.) only for new records, after this error was "Invalid trying locking recs in a transaction after take prior locks" (not a exactly transcription of error but there was the message), added a "rollback" in error routine until txnlevel()=0; the code as you see is very simple - things happens in that order:

1 user hit new()
2 edit record newly created
3 user hit save()
4 in save() method tableupdate() return .F. and execute rolback
5 error traped by error method called from save() method: "Uniqueness of index NUMAR is violated" (NUMAR is a candidate index other than IDDOC wich is the key)
6 user edit the field NUMAR and put something else
7 user hit save() again
8 error "Update conflict"

My question is how it is posibble to another in network edits a records that does not exist in table yet(this is Update conflict no?).
I expanded the handling of Update conflict and present the all fields with old values and disk values that appear to be: oldval() gets empty field and curval() gets actual values wich are imputed by user. The corect returns was supposed to be oldval() and curval() =.NULL. for appended records. This is happening after first save().
If I narrow down corectly things are like if 2 users hit new() at ~same moment and suppose table have 100 recs and they save newly record eachother instead to have 102 recs in table there are 101 recs. (this is not happening all the time)
This is what I try to avoid with =reccount() just prior to tableupdate() and then prior to APPEND BLANK (someone tell this force of read tableheader from disk and refresh fox internaly)

The primary key are stored in idkey table with fields tablename/chrpart/nrpart from where are taken like :
rlock
increment
update
unlock
return value

and stored in table through DefaultValue of field in DBC; I don't have two records with same key but from 2 recs appended (one from every PC) I get only one in parent (it seems not hapen in child)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform