Bonjour,
 
Comme certains le savent déjà, je m'apprete à modifier en urgence une appli qui accède à une base Access via DAO et Jet.
La nouvelle mouture devra quant à elle attaquer une base Oracle, via odbc donc.
Là j'ai plusieurs choix :
1) Tout passer en ADO (beaucoup de code à modifier).
2) Passer toujours par DAO avec ODBCDirect (à priori peu de choses à modifier, puisque tjrs DAO).
3) Accéder à odbc via DAO et Jet (ca risque de devenir très lent
 
A priori la solution 3) est la pire, j'aimerais donc savoir quels sont les difficultés que je pourrais rencontrer pour la 2) qui est le meilleur compromis, quitte à choisir la 1) plus tard (je rappelle que c'est du taf en urgence, la mise en prod est pour lundi prochain au plus tard).
 
Merci d'avance.
 
PS: On m'a déjà parlé des méthodes Seek et Find, lesquelles ne sont utilisées dans la version actuelle que dans une fonction.
PPS: Si vous pouviez en plus me donner des pistes pour contourner les problèmes que je risque de trouver, ce serait parfait!

Ouille, j'ai oublié de répondre
 
bon pour moi, c'est ADO parce qu'à la fin, c'est la seule interface qui sera encore supportée au long terme (en attendant de ne garder que .NET vu que c'est l'évolution finale du tout-Windows).
 
Les Find sont toujours utilisables en ADO. Je n'ai cependant pas assez d'expérience sur cette méthode pour te dire le changement que ça implique de passer de DAO à ADO.
 
Au niveau du Seek, soit tu passes à Find, soit tu utilises des requêtes bêtes et méchantes en remplacement. Ce sera d'autant plus facile si tu me dis que ça n'est utilisé que dans une seule fonction

Puisque tu réponds je mets à jour!
 
1) On a choisi ADO, et j'ai bossé tout hier à répertorier ce qui devait être changé dans le programme pour ça...
2) Aujourd'hui, boulot à 2 toute la journée (d'où mon peu de présence ici...:whistle
Evidemment tout ne marche pas du premier coup, donc on planche tjrs dessus pour un moment.:sweat:
 
Bon, j'en profite pour poser 2/3 questions (pas forcément VB, mais bon...:ange:
1) Le programme utilisait dans certaines requetes la fonction "FORMAT" pour mettre en forme des dates et obtenir un résultat de comparaison correct, hors Oracle ne connait pas ça...Il y a un équivalent Oracle? (on a pas encore reçu la doc...)
 
2)'tention celle-ci risque fortement de faire ressortir mon inexpérience en VB (et risque de pas être claire du tout!:D) : on a un formulaire avec des editbox (je suppose que c'est ça...j'ai l'impression qu'ils passent par un logiciel externe pour créer leurs brols) qui sont remplis avec des valeurs lues dans la bdd.
On remplit donc un recordset via une requête toute conne, et on affecte la valeur lue au .Text du contrôle en question.
Le problème est le suivant : quel que soit le type de la valeur lue, mon collègue la fait passer par une autre fonction avant de l'affecter au .text, et cette fonction retourne un Variant. Lorsque la valeur qu'on veut lire est une chaine tout va bien, par contre pour un numérique on obtient systématiquement 0 dans le .Text.
Cette valeur s'affiche d'ailleurs "0" dans le debugger, j'en déduis que la conversion Variant -> .Text se passe très mal et qu'au lieu de convertir mon numérique en chaine il essaie de lire une chaine directement dans le Variant.
 
Quelqu'un aurait une idée de ce qui se passe?(on sait jamais, des fois que quelqu'un comprenne ce que je raconte...:D)
 

pour le passage DB -> zones écran, le truc est que tout ce que le recordset renvoie est du Variant (propriété Value dans le Recordset).  Seulement, parfois, cette propriété Value peut donner la valeur Null, et celle-ci est incompatible avec les zones écran, il convient donc, pour un TextBox par exemple, de transformer la valeur en String.

Donc on est obligé de passer par une variable intermédiaire, donc...?

ben disons que tu testes le Variant avec la méthode IsNull(MonVariant) et s'il te retourne True, ben chaîne vide dans le contrôle, sinon tu peux taper le Variant dedans.

C'est en partie le boulot de la fonction que mon collègue utilise après avoir récupéré son recordset : elle retourne un variant qui est soit la valeur lue, soit une chaine vide.
Le problème c'est que la valeur de retour de cette fonction est bonne, mais l'affectation dans le .text se vautre (vaut zéro tout le temps).
C'est d'autant moins compréhensible que ca marchait très bien avec la base Access d'après lui...
C'est possible que ce soit un pb de type du champ correspondant? Sous access ca doit être un "numérique", et sous oracle un truc du style "number 7,0" (de tête, donc il est probable que je dise une grosse connerie).

ça c'est la fonction qu'on emploie sur SQL Server pour les chaînes.
 

 
pour un autre type, tu remplaces "String" par le type VB adéquat
il est important que la valeur venant de la DB soit passée "ByVal".

Je le note! Donc utiliser une seule et même fonction pour le tout est pas possible...je me demande bien comment ca pouvait marcher avant son truc...