Salut,
 
Je développe une petite appli utilisant ADO 2.6 et une base Access.
 
Et je suppose que si la machine cible ne possede pas la bonne librairie, alors l'appli ne marchera pas.
 
Mais comment faire pour connaitre les librairies que possede une machine?
 
Et sinon, puis je accéder sur la machine cible a des fichiers Access (par mon programme) si la machine cible ne possede pas Access?
 
Merci.

Ah oui, et je précise que je souhaite connaitre ces librairies sans utiliser d'environnement VB ou autre, car je voudrais avoir cette liste pour n'importe quelle machine.

Le mieux c'est de redistribuer les MDAC avec ton application, qui contiennent toutes les DLL d'accès aux données genre ADO, ADOX, DAO, OLEDB, etc.

D'accord, donc, tu ne connais pas de moyen de savoir facilement les librairies présentes?
 
Sinon, imaginons que je développe une appli en utilisant ADO 2.8, mais n'utilisant que des méthodes présentes dans les versions précédentes, est ce qu'un PC possédant ADO v2.5 pourra faire tourner mon appli?

Bof, on sait jamais ce qu'il y a eu comme changement. Les mêmes fonctions peuvent avoir des résultats différents

Et de toute manière quand on référence du 2.8, si l'appli trouve du 2.5, elle va faire une belle erreur

Ah bon?
 
Car d'une part, je vois que le fichier, que ce soit poiur ADO 2.5 ou ADO 2.8, est le meme : msado15.dll  
 
Et moi meme, plus habitué au monde C++, l'un des gros avantages des DLLs, si on s'y prend correctement, est qu'on puisse les upgrader, tout en gardant une sorte de rétro compatibilité pour les anciens programmes utilisant des anciennes versions (ou vice versa), du moment que les signatures des fonctions restent les memes (meme si l'implémentation interne change)

Moi j'avais justement le problème, j'utilisai les ADOX (donc un truc de ADO pour créer des base access via du code) 2.8. Après un formatage (et donc j'était revenu aux 2.7), ça refusait de prendre les 2.7 à la place des 2.8

Donc, le mieux est toujours de faire référence dans son code VB aux librairies d'une version assez "vieille" du genre 2.6 de maniere a ce que tous les ordis disposant du MDAC minimum 2.6 (installé par exemple avec SQL Server 2000) puisse tourner avec notre prog, et peut etre aussi les systemes avec une version plus avancée?

En gros, ouais...

Au fait, une question... Tu as un nForce2 toi aussi?

Euh... non je crois pas J'ai un machin SIS (ordi portable)

Oups, mdr, je me suis trompé de topic (tu dois me prendre pour un fou ) Il s'agissait ici d'un topic sur un probleme que je rencontre avec mes enceintes

Arf

Tiens, tant qu'on y est, vu que tu as l'air d'avoir de la bouteille en VB, je me posais une question...
 
Sous VBA Access, les combo boxes et list boxes pouvaient afficher plusieurs colonnes... Est ce que c'est possible sous VB également? Je trouvais cette possibilité hyper pratique...

Ca doit être possible ouais, c'est les mêmes contrôles je crois... Faut regarder au niveau des propriétés, style nombre de colonne, etc

Bah moi aussi, je pensais que c'étaient les memes controles, mais je me rends compte que les propriétés sont différentes (par exemple, pour la List Box...)
 
Ouh la la, on m'avait toujours dit que la transition VBA=>VB était aisée, mais j'ai l'impression qu'on y perd au change... (ou alors peut etre n'ai je pas regardé au bon endroit?)

Les libertés sont plus grandes en VB qu'en VBA. (sauf pour un travail précis dans une application comme Word , Excel ...)

Ouaip, normalement on peut faire plus de choses en VB par rapport à VBA.

Bah je veux bien, c'est pour ca que je m'en réjouissais.
 
Mais que veut dire "libertés plus grandes"? Car si c'est au détriment de la facilité et la rapididté, alors pour mon appli, autant me tourner vers C++ ou la liberté est quasi totale.
 
Mais alors, il est possible ou pas d'avoir des listes a plusieurs colonnes comme sous VBA?

Après un rapide petit détour par Excel, je peux te dire que c'est réalisable.
Pour cela il te suffit d'ajouter le contrôle ' msflexgird ' à ta feuille et tu as une liste à plusieurs colonnes.

Mais il n'y a pas moyen d'afficher une liste a plusieurs colonnes comme dans Access? Je tombe un peu des nues...
 
Et si j'utilise des controles ActiveX externes, est ce que mon appli va marcher sur d'autres applis?

• Normalement oui. Je n'ai jamais essayé.
 
• Les controles ActiveX sont rétilisables tant que tu les référencies correctement. Dans VB6, fait un clic droit sur la boîte à outils et fait 'Ajouter des composants ...'

Tiens, je crois que je viens de trouver mon bonheur:
Le controle "ComboBox" issu du groupe de controles "MS Forms 2.0"
 
Mais par contre, est ce qu'il va falloir que la machine cible installe quelque chose ou pas? Telle est la question...
 
Il y avait un truc que j'aimais bien aussi avec les ListBox Access, dans le cadre d'une source de données, c'était la possibilité de copier toutes les donnees dun coup dans la ListBox, de maniere Ultra rapide, avec une méthode du genre CopyData... Bon, tout ca reste a voir!
 

Il faut que tu cherches un peu.    
Pour ce qui est de tes contrôles : pour fonctionner, la machine client (celle sur laquelle tournera l'application) doit être munie au minimun de ' vb6fr.dll '(sinon un message t'informera que le contôle est manquant et le programme ne s exécutera pas.)   .
Pour ce qui est des contrôles supplémentaires (que tu ajoutes en faisant ' Projet ' > ' Composants ... ') il faut que les fichiers .ocx ou .dll dont tu fais référence soient sur la machine cliente. Si ce n'est pas le cas, un coup de copier/coller du contrôle peut faire l'affaire.  
J'ai oublié un truc : les éléments se trouvent en général dans ' C:\WINDOWS\System32\ ' (XP & 2000) ' C:\WINDOWS\System\ ' pour le reste.

Mais un controle de type ocx par exemple doit etre enregistré, non? Sur la machine cliente? (dans le sens "registered"?
 
Sinon, a quoi sert vb6fr.dll? Pour ma part, vu que tout mon OS, ainsi que mon ordi et mon Visual Studio viennent d'Angleterre, je suppose qu'il me faudra un autre fichier, non? Je vais me renseigner pour cela.

Si tu a Visual Studio .Net, il te faudra le .NET framwork de microsoft
Sinon cherche une dll contanant 'VB6'
Sinon effectivement il faudrait les enregistrer dans le système client mais bon à défaut de, moi je copie/colle et c'est passé.

Salut,
 
Me revoila...
 
Bon, quand j'essaie de comprendre les choses, je me perds un peu.
 
Alors, voici en gros le truc...
 
Je prends un projet VB tout simple, que je compile.  
Je fais cela avec mon Laptop (Win2k et Visual Basic 6 versions anglaises).
Alors, je lance Dependency Walker, et rien de spécial a signaler.
 
Je prends la meme appli compilée, et je la copie sur mon ordi de bureua (WinXP version francaise). La, je lance l'appli, et ca marche normal.
 
Alors, je lance Dependency Walker, et la, das le listing lors du profiling (cad que je lui demande de lancer l'appli pour détecter toutes les dll appelées), il me dit a un moment en rouge:  
 

 
Mais ca n'empeche pas l'appli de fonctionner...
 
Je ne comrends pas comment il peut chercher a trouver ce vb6fr.dll, alors que sur l'ordi sur lequel jai compilé lappli (mon portable), l'OS et VB6 sont en anglais et qu'en plus, vb6fr.dll n'existe nulle part sur le disque...
 
Vous auriez une explication?

Cela s'appelle la magie de Windows .
Là j'avoue ne pas savoir.
A moins que VB6fr.dll ne reprenne qu'une partie du Runtime de VB6.
(Le runtime est un fichier compressé contenant tous les fichiers (généraux) pour éxécuter une application.)