Tester si un recordset est vide [RESOLU, merci] - VB/VBA/VBS - Programmation
Marsh Posté le 02-06-2003 à 19:48:08
ne fait jamais de select dans un execute, d'un driver ABDOB à l'autre tu auras un résultat valide ou non, puisque c'est une procédure et non une fonction.
dim cnx as ADODB.connection |
là ça fonctionnera correctement.
Marsh Posté le 02-06-2003 à 19:48:52
Et réserve le "cnx.Execute sql" pour les insert, update et delete.
Marsh Posté le 02-06-2003 à 20:01:44
le pb doit etre autre part car eof et bof marche tj, sinon tu peux utiliser rs.recordcount
Marsh Posté le 02-06-2003 à 20:18:27
minours666 a écrit : le pb doit etre autre part car eof et bof marche tj, sinon tu peux utiliser rs.recordcount |
JAMAIS !
SQL Server + jointure plus une fonction de regroupement, et le recordcount = -1 systématiquement.
Drivers ODBC d'Oracle, recordcount = -1 systématiquemet.
Cette propriété est à banir, tout comme le movelast et le moveprevious, ou le move
Les seuls moves acceptés sont le movenext et le movefirst.
Pour le reste, d'une version du drivers à l'autre, tu risques d'avoir des résultat incohérents ou carrément des plantages.
Marsh Posté le 02-06-2003 à 21:17:01
J'ai pas encore tenté la soluce de Magicbuzz, mais je confirme que le recordcount ne fonctionne pas...
D'ailleurs ca porte très mal son nom et j'en comprends pas l'utilisation...
Marsh Posté le 02-06-2003 à 21:19:29
superchinois a écrit : J'ai pas encore tenté la soluce de Magicbuzz, mais je confirme que le recordcount ne fonctionne pas... |
c'est censé retourner le nombre de lignes retournées par la requête. Mais ça marche quand ça veut, c'est à dire rarement.
Tu n'auras un fonctionnement à peut près stabe qu'avec les drivers OLE DB, et MS JET je crois, et encore, c'est soumis à conditions.
Marsh Posté le 02-06-2003 à 21:20:09
et au fait, n'ouvre pa le recordset en dynamique, sinon il va inserrer une ligne contenant que des "null" dedans, qui te permet d'inserrer une ligne dans la table.
Marsh Posté le 02-06-2003 à 21:46:26
MagicBuzz a écrit : ne fait jamais de select dans un execute, d'un driver ABDOB à l'autre tu auras un résultat valide ou non, puisque c'est une procédure et non une fonction. |
ah? pourtant VB est formel: Execute est une fonction renvoyant un recordset
Marsh Posté le 02-06-2003 à 21:52:15
le recordcount est valide en fonction du type de curseur que tu utilises pour ouvrir ton recordset. Avec le type forwardonly, c'est certain, il n'est pas utilisable.
Par contre avec ce type, tu sais tout de suite si ton recordset est vide car il se positionne automatiquement sur le premier enregistrement: tu testes EOF. S'il est a True, ton recordset est vide.
Marsh Posté le 02-06-2003 à 23:22:37
drasche a écrit : |
c'est une surcharge de la procédure.
si tu passes une requête qui retourne un résultat à un "execute", ça fait implicitement un open.
seulement, d'une version des drivers à l'autre (d'un sgbd à l'autre surtout) ça marche pas toujours comme escompté. il est donc fortement recommandé d'utiliser le .open du recorsdet qui est à ça.
Marsh Posté le 03-06-2003 à 07:22:03
ouais j'aurais dû préciser que je suis pour le Open aussi, naturellement
il offre plus de possibilités quand aux types de curseurs et de locks.
Marsh Posté le 02-06-2003 à 19:34:15
Salut
Voilà, j'exécute la requête suivante:
Set rstnofact = DataEnvironment.connectionBD_resto.Execute("SELECT max(numéro) FROM factures" )
Ma table "Factures" étant volontairement vide, rsnofact ne devrait pas contenir d'enregistrements.
Ainsi, on devrait avoir logiquement:
rsnofact.BOF = true and rsnofact.EOF = true
Mais ça n'est pas le cas et j'ai absolument besoin de tester si rstnofact contient des enregistrements ou pas.
Qqun saurait-il m'aider?
Message édité par superchinois le 03-06-2003 à 15:42:51