Information générale
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Network:
Windows 2003 Server
I tried to figure out if the same behaviour would occur on a "simple" delete.
Basically I thought that maybe it does
FOR EACH Record_in_the_Scope
RLOCK()
See if it matches criteria
Update (Delete) if necessary
UNLOCK
ENDFOR
for *any* scope after rushmorizing it.
The idea being that in the "2nd join" case this scope is entire table.
So I tried to execute DELETE on a *partially* optimizable WHERE condition like this one:
DELETE FROM Resource WHERE MainId = 12345 and Type="1"
where MainId is optimizable and Type is not. I thought if I RLOCK the record that matches this criteria by its MainId part but doesn't match its Type part, I would see the same behaviour when VFP would try to attempt a lock because my record is within the optimized part. Well, it didn't...
And of course since DELETE is just an update of a special column, UPDATE command is no different in behaviour.
I don't know what to think now. I mean, other that it is a bug.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement