Bonjour,

Voila mon problème :

Je developpe des applications qui sont dans 90% des cas en relation avec les bases de données Clients, Fournisseurs, Articles et Prospects des logiciels de gestion que l'on vends à coté.

Ces bases sont en général des .mdb

J'aimerai me faire un composant qui me permette d'afficher la liste des clients / prospects / fournisseurs dans mes applications, et que ce composant prenne en charge les divers types de bases .mdb existantes.

J'ai commencé un composant avec une requete de recherche pour chaque type de base (toutes les requetes ont la même signature, ce qui me permet d'utiliser les indirections), ensuite dans l'initialisation du composant, je donne simplement le chemin du .mdb et le type de données voulu (clients / artcles...). J'execute ma requete, et je fait un



Dans le composant, ça marche, mais une fois dans un projet, le ConstruitTableFichier(_table,_requete,taRemplirTable) executé à l'interieur du composant n'affecte pas la table du projet...

J'imagine que c'est parceque le projet n'a pas accés aux requetes du composant.

Par contre je peux parcourir la requete depuis le composant, et faire des "TableAjouteLigne", là ça fonctionne, mais c'est trés lent, et pas vraiment pratique.

Donc en gros, j'aimerai savoir comment vous faites pour avoir des produits liables à des bases de types différents, sans avoir à réintegrer toutes les requêtes / code pour chaque nouveau projet ?

Merci d'avance,

Seb

PS : passer par du SQLexec ne m'interesse pas, car si je fait ça sur des bases autres que HF, je suis obligé de déclarer des sources ODBC sur chaque poste.

Bonjour,
Les composant qui inter-agissent avec les projets doivent suivre un certain nombre de règles simples inhérente à la portabilité du-dit composant dont en voici les deux principales (pour les autres, je ne suis encore en mesure de toutes les répertoirier ni de les organiser) :

- Pour accéder depuis l'extérieur du composant a ses éléments (valeur de champs etc etc), toujours proposer des procédures ou fonctions (ou méthodes de classes). Ne pas laisser l'utilisateur du composant aller 'piocher' lui même dans ce dernier.

- Dans l'autre sens, Idem, toujorus proposer des procédure/méthode qui recevront en paramètre le "chemin" des information du projet. Par "Chemin" je fais référence au paragraphe "Le chemin des variables" de ce dossier.

Ainsi dans votre cas, la procédure de recherche devra stipuler le chemin du champ table dans lequel les données seront envoyées.



Coté composant, il suffira d'utiliser les paramètres, l'indirection et les énumération pour envoyer les données :

Oui, c'est exactement comme ça que j'ai procédé, (même si je n'ai pas forcement expliqué ça de manière limpide). Mais ça ne fonctionne pas plus.

Moi je passait en paramètre le chemin complet de la table, entre guillemets : "maFenetre.maTable", j'ai aussi essayé "maTable", ou simplement maTable. Avec maTable..nom, le résultat est le même...

Bizarre,
Il doit y avoir un détail qui nous échappe, l'utilisation des chemins des information demande une bonne connaissance de l'environnement d'exécution (noms des éléments et présence en mémoire).

Je n'ai pas testé ce cas précis mais cela mérite qu'on s'y penche.

Essayer lors de la création du composant de définir que celui-ci peut intéragir avec les fenetres et objets du projet client (projets où le composant serait intégré).
Cette option est disponible dans le bouton "options" ou "description" du composant dans la fenêtre "Composants générés par ce projet".

Cordialement
@++