Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Append Blank or Insert Into?
Message
De
11/12/1998 10:16:32
Beth Wetherbee
Virginia Beach Public Schools
Virginia Beach, Virginie, États-Unis
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00136359
Message ID:
00166566
Vues:
23
Jim,

>>That's a good point Jim. Let me check that I understand you, if I go INSERT INTO (PKey) VALUES (akeyvalue).... into a buffered table it doesn't get to the underlying table until TableUpdate() anyway, so the server index is only updated after that point, so it doesn't matter whether or not I use append blank or insert??
>>You seem to be implying that INSERT INTO ... can't create a blank record in a buffered table.
>
>David,
>
>INSERT INTO will create a blank record, but so will append blank. wITH BUFFERING THERE IS NOT DIFFERENCE:

Along these lines, I have discovered some behavior that I can't understand. If I:

1) Open a table with a primary key index
2) Set buffering to 5 - optimistic table
3) Go to a record and issue a scatter memvar
4) Issue "insert into mytable from memvar" OR append blank/gather
5) Move the record pointer off that record
- I get a "Uniqueness of primary key violated" error, even though I haven't issued a TABLEUPDATE().

This would seem to indicate that there is some 'updating' of the index happening before the TABLEUPDATE() is issued. I can sort of understand why that would happen in this situation. But, if I:

A) "Set deleted on" to ignore deleted records
B) Do steps 1-3 above
C) Delete the record I used for the SCATTER MEMVAR
D) Do steps 4 and 5 above
- I get the same error message, even though the first record was deleted and "set deleted" is on.

At first I thought that moving the record pointer was causing a TABLEUPDATE() the way it does when row buffering is on, but if I just add a record that doesn't have a duplicate primary key, move the record pointer and then close the table without a TABLEUPDATE(), the record doesn't stay. This seems to be consistent with how table buffering is supposed to work, but isn't very consistent with the behavior I described above.

This is causing a problem for me, partly because of poor table design. Unfortunately, I inherited the table design and can't really go back and change it now. Regardless though, this behavior doesn't make sense to me. Can you shed some light on this?

Thanks!
Beth Wetherbee, MCSD
VBCPS
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform