Je cherche à utiliser plusieurs connexion à des bases firebird
differentes, dans l'initialisation du projet, j'ai mis le code suivant :
// declarations globales
gsGESCOM_DBServer est une chaîne
gsGESCOM_DBDatabase est une chaîne
gsGESCOM_DBUser est une chaîne
gsGESCOM_DBPassword est une chaîne
gclGESCOM_DBConnexion est un c_FB4WD
gsSTOCK_DBServer est une chaîne
gsSTOCK_DBDatabase est une chaîne
gsSTOCK_DBUser est une chaîne
gsSTOCK_DBPassword est une chaîne
gclSTOCK_DBConnexion est un c_FB4WD
// Connexion a la base GESCOM
gsGESCOM_DBServer="192.168.0.226"
gsGESCOM_DBDatabase="c:\gescom_tests\base_test.fdb"
gsGESCOM_DBUser="SYSDBA"
gsGESCOM_DBPassword="masterkey"
SI PAS
gclGESCOM_DBConnexion:mySQLConnecte(gsGESCOM_DBServer,gsGESCOM_DBDatabase,gsGESCOM_DBUser,gsGESCOM_DBPassword)
ALORS
Info("Pas de Conenxion SQL GESCOM :
"+gclGESCOM_DBConnexion:mySQLGetErrorMessage())
FinProgramme()
FIN
// Connexion a la base GESTION_STOCK
gsSTOCK_DBServer="192.168.0.226"
gsSTOCK_DBDatabase="c:\gescom_tests\BASE_STOCK_ENGP.FDB"
gsSTOCK_DBUser="SYSDBA"
gsSTOCK_DBPassword="masterkey"
SI PAS
gclSTOCK_DBConnexion:mySQLConnecte(gsSTOCK_DBServer,gsSTOCK_DBDatabase,gsSTOCK_DBUser,gsSTOCK_DBPassword)
ALORS
Info("pas de Connexion SQL STOCK :
"+gclSTOCK_DBConnexion:mySQLGetErrorMessage())
FinProgramme()
FIN
Mais j'ai l'impression que la deuxieme connexion ecrase la première (si
j'enleve la deuxieme connexion, les requetes sur GESCOM focntionnent). Y
a t il une astuce qui m'aurait échapé ?
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
"Jerome PAULIN" a écrit dans le message de news: 454f701f$0$22121$
Bonjour,
excusez moi de me méler de votre affaire: il me semble que ChargeDLL(:DLLName+".dll") va chercher la DLL dans le répertoire en cours qui est celui des données. Donc, faudrait peut-être essayer avec ChargeDLL(fRepExe()+""+:DLLName+".dll")
Salutations Mat
Bonsoir,
Toute aide est, je le pense, intéressante...
J'ai essayé ta proposition ret j'obtiens le message suivant :
Erreur à la ligne 48 du traitement constructeur de la classe c_FB4WD. Vous avez appelé la fonction AppelDLL32. Erreur au chargement de la DLL 'fb4wd2'
Détail de l'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide. (998)
Informations techniques
Projet : EMGP_gestion_stocks
Dump de l'erreur du module <WD100VM.DLL> <10.01Fg>.
- Appel WL : Traitement de <c_FB4WD.Constructeur>, ligne <48>, thread <0> Fonction <AppelDLL32>, n° de syntaxe <0>
- Niveau : erreur fatale (EL_FATAL)
- Code erreur : 2802
- Code erreur WD55 : 0
- Code d'erreur système : 998
- Message d'erreur système : L'accès à cet emplacement de la mémoire n'est pas valide.
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte.
seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
"Jerome PAULIN" <gg@gg-s.net> a écrit dans le message de news:
454f701f$0$22121$426a34cc@news.free.fr...
Bonjour,
excusez moi de me méler de votre affaire: il me semble que
ChargeDLL(:DLLName+".dll") va chercher la DLL dans le répertoire en cours
qui est celui des données. Donc, faudrait peut-être essayer avec
ChargeDLL(fRepExe()+""+:DLLName+".dll")
Salutations
Mat
Bonsoir,
Toute aide est, je le pense, intéressante...
J'ai essayé ta proposition ret j'obtiens le message suivant :
Erreur à la ligne 48 du traitement constructeur de la classe c_FB4WD.
Vous avez appelé la fonction AppelDLL32.
Erreur au chargement de la DLL 'fb4wd2'
Détail de l'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide.
(998)
Informations techniques
Projet : EMGP_gestion_stocks
Dump de l'erreur du module <WD100VM.DLL> <10.01Fg>.
- Appel WL :
Traitement de <c_FB4WD.Constructeur>, ligne <48>, thread <0>
Fonction <AppelDLL32>, n° de syntaxe <0>
- Niveau : erreur fatale (EL_FATAL)
- Code erreur : 2802
- Code erreur WD55 : 0
- Code d'erreur système : 998
- Message d'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide.
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
"Jerome PAULIN" a écrit dans le message de news: 454f701f$0$22121$
Bonjour,
excusez moi de me méler de votre affaire: il me semble que ChargeDLL(:DLLName+".dll") va chercher la DLL dans le répertoire en cours qui est celui des données. Donc, faudrait peut-être essayer avec ChargeDLL(fRepExe()+""+:DLLName+".dll")
Salutations Mat
Bonsoir,
Toute aide est, je le pense, intéressante...
J'ai essayé ta proposition ret j'obtiens le message suivant :
Erreur à la ligne 48 du traitement constructeur de la classe c_FB4WD. Vous avez appelé la fonction AppelDLL32. Erreur au chargement de la DLL 'fb4wd2'
Détail de l'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide. (998)
Informations techniques
Projet : EMGP_gestion_stocks
Dump de l'erreur du module <WD100VM.DLL> <10.01Fg>.
- Appel WL : Traitement de <c_FB4WD.Constructeur>, ligne <48>, thread <0> Fonction <AppelDLL32>, n° de syntaxe <0>
- Niveau : erreur fatale (EL_FATAL)
- Code erreur : 2802
- Code erreur WD55 : 0
- Code d'erreur système : 998
- Message d'erreur système : L'accès à cet emplacement de la mémoire n'est pas valide.
Jerome PAULIN
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte.
seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir
des connexions vers plusieurs bases en Delphi.
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
mat
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte.
seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir
des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il
pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre
connexions en cours?...
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
Nicolas
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
"mat" a écrit dans le message de news:
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une
couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir
plusieurs bases en même temps, et que bien sûr il n'y a pas à charger
plusieurs fois fbclient.dll.
"mat" <NoSPAM-mnobs@windasso.org> a écrit dans le message de news:
4rb2gfFqltaoU1@mid.individual.net...
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte.
seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir
des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il
pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre
connexions en cours?...
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
"mat" a écrit dans le message de news:
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
Firetox
Bonjour,
oui mais la classe windev charge plusieurs dll FB4WD.dll et si celle ci charge la dll fbclient alors probleme mais si on ne charge pas 2 FB4WD.dll differentes, il n'y a qu'un contexte firebird et c'est la derniere qui est active comme il le dit dans son premier message comme c'est la dll FB4WD qui controle le chargement de la FBclient.dll si on charge 2 fois cette dll (FB4WD.dll sous 2 noms differents elle va charger 2 fois la fbclient)
donc voila pourquoi je dit que c'est comme sous mysql c'est api firebird qui controle tout ca . en borland c++ j'ai pas de souci non plus pour avoir plusieurs base. et vous non plus avec les API directe. la dll FB4WD s'appuie sur ces api via la fbclient donc quid du chargement de plusieurs FB4WD.dll : je pense que le fait de la charger plusieurs fois entraine le chargement de la fbclient.dll plusiseurs fois : ce qui n'est pas permis
bref seul manu peut nous dire si dans la FB4WD.dll il peut faire quelque chose
"Nicolas" a écrit dans le message de news: 45506911$0$27410$
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
"mat" a écrit dans le message de news:
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
Bonjour,
oui mais la classe windev charge plusieurs dll FB4WD.dll et si celle ci
charge la dll fbclient alors probleme
mais si on ne charge pas 2 FB4WD.dll differentes, il n'y a qu'un contexte
firebird et c'est la derniere qui est active comme il le dit dans son
premier message
comme c'est la dll FB4WD qui controle le chargement de la FBclient.dll si on
charge 2 fois cette dll (FB4WD.dll sous 2 noms differents elle va charger 2
fois la fbclient)
donc voila pourquoi je dit que c'est comme sous mysql c'est api firebird qui
controle tout ca .
en borland c++ j'ai pas de souci non plus pour avoir plusieurs base. et vous
non plus avec les API directe. la dll FB4WD s'appuie sur ces api via la
fbclient donc quid du chargement de plusieurs FB4WD.dll : je pense que le
fait de la charger plusieurs fois entraine le chargement de la fbclient.dll
plusiseurs fois : ce qui n'est pas permis
bref
seul manu peut nous dire si dans la FB4WD.dll il peut faire quelque chose
"Nicolas" <nospam@mail.com> a écrit dans le message de news:
45506911$0$27410$ba4acef3@news.orange.fr...
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une
couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir
plusieurs bases en même temps, et que bien sûr il n'y a pas à charger
plusieurs fois fbclient.dll.
"mat" <NoSPAM-mnobs@windasso.org> a écrit dans le message de news:
4rb2gfFqltaoU1@mid.individual.net...
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte.
seul manu pourrait confirmer a mais je pense que c'est comme pour
mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir
des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il
pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre
connexions en cours?...
oui mais la classe windev charge plusieurs dll FB4WD.dll et si celle ci charge la dll fbclient alors probleme mais si on ne charge pas 2 FB4WD.dll differentes, il n'y a qu'un contexte firebird et c'est la derniere qui est active comme il le dit dans son premier message comme c'est la dll FB4WD qui controle le chargement de la FBclient.dll si on charge 2 fois cette dll (FB4WD.dll sous 2 noms differents elle va charger 2 fois la fbclient)
donc voila pourquoi je dit que c'est comme sous mysql c'est api firebird qui controle tout ca . en borland c++ j'ai pas de souci non plus pour avoir plusieurs base. et vous non plus avec les API directe. la dll FB4WD s'appuie sur ces api via la fbclient donc quid du chargement de plusieurs FB4WD.dll : je pense que le fait de la charger plusieurs fois entraine le chargement de la fbclient.dll plusiseurs fois : ce qui n'est pas permis
bref seul manu peut nous dire si dans la FB4WD.dll il peut faire quelque chose
"Nicolas" a écrit dans le message de news: 45506911$0$27410$
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
"mat" a écrit dans le message de news:
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
Daniel
Bonjour,
Nicolas a écrit :
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
Peut être parceque tu as prévu un tableau de "connexion" dans ta dll d'interface? (ce qui n'est pas le cas dans fb4wd)
"mat" a écrit dans le message de news:
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bonjour,
Nicolas a écrit :
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une
couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir
plusieurs bases en même temps, et que bien sûr il n'y a pas à charger
plusieurs fois fbclient.dll.
Peut être parceque tu as prévu un tableau de "connexion" dans ta dll
d'interface?
(ce qui n'est pas le cas dans fb4wd)
"mat" <NoSPAM-mnobs@windasso.org> a écrit dans le message de news:
4rb2gfFqltaoU1@mid.individual.net...
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte.
seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir
des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il
pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre
connexions en cours?...
salutations
Mat
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
Peut être parceque tu as prévu un tableau de "connexion" dans ta dll d'interface? (ce qui n'est pas le cas dans fb4wd)
"mat" a écrit dans le message de news:
Jerome PAULIN wrote:
Firetox a écrit :
Bonjour,
je pense que fbclient.dll n'accepte pas le multi contexte. seul manu pourrait confirmer a mais je pense que c'est comme pour mySQL.
Dans ce ca il n'y aurait pas de solution ? J'arrive pourtant à me ouvrir des connexions vers plusieurs bases en Delphi.
gg
encore moi :-)
pourquoi avoir besoin fbclient.dll en mémoire plus qu'une fois? N'est-il pas suffisant une fois et ne pas la décharger lorsqu'il y a d'autre connexions en cours?...
salutations Mat
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Emmanuel LECOESTER
"Nicolas" a écrit dans le message de news: 45506911$0$27410$
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
Nickel. Vous utilisez les API de base ? Si oui vous auriez un exemple de votre fonction connect histoire de voir comment vous faites.
Merci d'avance.
"Nicolas" <nospam@mail.com> a écrit dans le message de news:
45506911$0$27410$ba4acef3@news.orange.fr...
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une
couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir
plusieurs bases en même temps, et que bien sûr il n'y a pas à charger
plusieurs fois fbclient.dll.
Nickel. Vous utilisez les API de base ? Si oui vous auriez un exemple de
votre fonction connect histoire de voir comment vous faites.
"Nicolas" a écrit dans le message de news: 45506911$0$27410$
Nous utilisons Firebird avec Windev (pas par SQLManagerX mais avec une couche à nous sur les API de Firebird), et je confirme qu'on peut ouvrir plusieurs bases en même temps, et que bien sûr il n'y a pas à charger plusieurs fois fbclient.dll.
Nickel. Vous utilisez les API de base ? Si oui vous auriez un exemple de votre fonction connect histoire de voir comment vous faites.
Merci d'avance.
Emmanuel LECOESTER
"Jerome PAULIN" a écrit dans le message de news: 454f701f$0$22121$
Bonjour,
excusez moi de me méler de votre affaire: il me semble que ChargeDLL(:DLLName+".dll") va chercher la DLL dans le répertoire en cours qui est celui des données. Donc, faudrait peut-être essayer avec ChargeDLL(fRepExe()+""+:DLLName+".dll")
Salutations Mat
Bonsoir,
Toute aide est, je le pense, intéressante...
J'ai essayé ta proposition ret j'obtiens le message suivant :
Erreur à la ligne 48 du traitement constructeur de la classe c_FB4WD. Vous avez appelé la fonction AppelDLL32. Erreur au chargement de la DLL 'fb4wd2'
Détail de l'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide. (998)
Bon j'arrive à la même chose que vous dans mes tests (c'est une bonne chose, j'arrve à le reproduire). Je vois çà avec la team IBPP pour comprendre d'où celà peut venir car je n'utilise rien de particulier. Je vous tiens au courant.
"Jerome PAULIN" <gg@gg-s.net> a écrit dans le message de news:
454f701f$0$22121$426a34cc@news.free.fr...
Bonjour,
excusez moi de me méler de votre affaire: il me semble que
ChargeDLL(:DLLName+".dll") va chercher la DLL dans le répertoire en cours
qui est celui des données. Donc, faudrait peut-être essayer avec
ChargeDLL(fRepExe()+""+:DLLName+".dll")
Salutations
Mat
Bonsoir,
Toute aide est, je le pense, intéressante...
J'ai essayé ta proposition ret j'obtiens le message suivant :
Erreur à la ligne 48 du traitement constructeur de la classe c_FB4WD.
Vous avez appelé la fonction AppelDLL32.
Erreur au chargement de la DLL 'fb4wd2'
Détail de l'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide.
(998)
Bon j'arrive à la même chose que vous dans mes tests (c'est une bonne chose,
j'arrve à le reproduire). Je vois çà avec la team IBPP pour comprendre d'où
celà peut venir car je n'utilise rien de particulier. Je vous tiens au
courant.
"Jerome PAULIN" a écrit dans le message de news: 454f701f$0$22121$
Bonjour,
excusez moi de me méler de votre affaire: il me semble que ChargeDLL(:DLLName+".dll") va chercher la DLL dans le répertoire en cours qui est celui des données. Donc, faudrait peut-être essayer avec ChargeDLL(fRepExe()+""+:DLLName+".dll")
Salutations Mat
Bonsoir,
Toute aide est, je le pense, intéressante...
J'ai essayé ta proposition ret j'obtiens le message suivant :
Erreur à la ligne 48 du traitement constructeur de la classe c_FB4WD. Vous avez appelé la fonction AppelDLL32. Erreur au chargement de la DLL 'fb4wd2'
Détail de l'erreur système :
L'accès à cet emplacement de la mémoire n'est pas valide. (998)
Bon j'arrive à la même chose que vous dans mes tests (c'est une bonne chose, j'arrve à le reproduire). Je vois çà avec la team IBPP pour comprendre d'où celà peut venir car je n'utilise rien de particulier. Je vous tiens au courant.
Jerome PAULIN
Emmanuel LECOESTER a écrit :
Bon j'arrive à la même chose que vous dans mes tests (c'est une bonne chose, j'arrve à le reproduire). Je vois çà avec la team IBPP pour comprendre d'où celà peut venir car je n'utilise rien de particulier. Je vous tiens au courant.
Effectivement, c'est deja un grnad pas en avant que de reussir a reproduire le probleme ...
Pour mon projet, j'ai cree ma base de travail avec MySQl au lieu de Firebird, j'utilise SQLManagerX pour transferer les donnees et l'acces natif pour la base MySQL, je retenterai quand vous nous aurez trouvé une solution (ce n'est, a mon avis, qu'une question de temps)...
Merci de votre aide,
Jerome PAULIN
Emmanuel LECOESTER a écrit :
Bon j'arrive à la même chose que vous dans mes tests (c'est une bonne chose,
j'arrve à le reproduire). Je vois çà avec la team IBPP pour comprendre d'où
celà peut venir car je n'utilise rien de particulier. Je vous tiens au
courant.
Effectivement, c'est deja un grnad pas en avant que de reussir a
reproduire le probleme ...
Pour mon projet, j'ai cree ma base de travail avec MySQl au lieu de
Firebird, j'utilise SQLManagerX pour transferer les donnees et l'acces
natif pour la base MySQL, je retenterai quand vous nous aurez trouvé une
solution (ce n'est, a mon avis, qu'une question de temps)...
Bon j'arrive à la même chose que vous dans mes tests (c'est une bonne chose, j'arrve à le reproduire). Je vois çà avec la team IBPP pour comprendre d'où celà peut venir car je n'utilise rien de particulier. Je vous tiens au courant.
Effectivement, c'est deja un grnad pas en avant que de reussir a reproduire le probleme ...
Pour mon projet, j'ai cree ma base de travail avec MySQl au lieu de Firebird, j'utilise SQLManagerX pour transferer les donnees et l'acces natif pour la base MySQL, je retenterai quand vous nous aurez trouvé une solution (ce n'est, a mon avis, qu'une question de temps)...
