Travailler en asynchrone avec un recordset ADO

Bonjour à tous,

J'expérimente actuellement l'ouverture générique (requête et arguments d'ouvertures variables) en asynchrone d'un recordset ADO attaquant une base SQL Server (sous VB6).
Tout fonctionne correctement (l'appli n'est pas suspendue pendant le traitement de la requête et le retour des enregistrements par le serveur), mais il me manque une information importante : le nombre d'enregistrements total retournés par la requête, avant même le chargement des enregistrements du coté client.
En effet, j'avais imaginé pouvoir afficher le pourcentage de récupération des enregistrements, histoire d'assurer un minimum de transparence pour l'utilisateur.
J'ai essayé diverses méthodes, mais aucune ne m'a permit de récupérer la précieuse information, à savoir :
- interrogation de RecordCount au premier évènement FetchProgress => provoque le chargement total du recordset en mode synchrone... (ma foi c'est logique)
- concaténation de "; PRINT @@ROWCOUNT" à la suite de la chaine SQL, dans le but de provoquer une erreur voulue, mais cette erreur ne se produit jamais (d'ailleurs, la concaténation de "; PRINT 1/0" ne provoque aucune erreur non plus... j'en conclu donc que la méthode Open s'arrête au premier lot de la chaine SQL contenant une clause SELECT)
- utilisation de la méthode Execute de l'object Connection en asynchrone, à la place de Open du recordset, d'une part pour tenter d'utiliser l'argument par référence RecordsAffected (ne fonctionne pas); et d'autre part de récupérer @@ROWCOUNT part la concaténation de "; SELECT ROWCOUNT" à la fin de la chaine contenant la requête, mais ça ne marche pas non plus.

J'avoue arriver un peu à court de solutions, et apprécierait grandement vos avis experts

J'y avais pensé, en effet, mais cette solution n'est pas sans inconvénients :
- on a donc deux requêtes exécutées dans deux lots différents, par conséquent le nombre d'enregistrements comptés peut différer entre les deux résultats (accès concurrentiel oblige).
- dans le cas où l'analyse de la requête par le serveur est assez long, on va donc doubler le temps d'attente du coté de l'application cliente.

oui j' ai compris ton soucis ;
Alors il y' a peut être une solution rocambolesque :-)
Elle consiste à passer ta requete selection comme une requete regroupement sur cle primaire en premier et First pour le reste.
Et en dernier Count(ClePrimaire).
Tu auras ainsi combiné les deux:
Retour des enregistrements et et total des enregistrements.
Si ça ne marche pas, retour à la première solution avec execution de la requete (Count)  tout les n secondes.

... Y'en a même qui disent qu'ils l'ont vu voler.

Hum... tu m'as l'air au moins aussi tordu que moi ^^
Ton idée est intéressante, mais inapplicable dans mon cas, ma fonction devant rester générique au niveau des requêtes, on a pas forcément de clé primaire (certaines requêtes imbriquées, multi-niveaux (MSDataShape)). Et surtout.. le résultat de la requête doit demeurer conforme à ce qui est demandé par la requête d'origine.
Personnellement, j'avais pensé à un moment faire un INSERT dans une table temporaire pour interroger son count, puis renvoyer son contenu à l'aide d'un SELECT, mais cette voie ressemble plus à une usine à gaz qu'à autre chose.
Tout bien réflechi, ce total que je cherche à récupérer est une information simplement indicative pour afficher un pourcentage d'exécution, et étant donné que la plupart du temps il sera exact en utilisant ta première solution, je pense que je vais l'adopter.
En te remerciant encore de ton aide.. :)