Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable
out de procédure stockée??
J'ai essayé avec Oracle4WD, ca marche très bien, mais étant donné que
mon projet utilise bcp l'instruction SQLTable et que la version
"PCSoft" est bcp bcp plus rapide (j'ai testé sur une requête qui ramène
environ 3000 enregistrement, c'est 0.5 secondes pour le natif, et 5
secondes pour l'(alter)natif.
J'aimerais si possible éviter d'utiliser les deux accès dans la même
appli, mais si je n'ai pas le choix, je me résoudrais à le faire.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Manu
> Hello.
Bonjour Gilles,
Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable out de procédure stockée??
J'ai essayé avec Oracle4WD, ca marche très bien, mais étant donné que mon projet utilise bcp l'instruction SQLTable et que la version "PCSoft" est bcp bcp plus rapide (j'ai testé sur une requête qui ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif, et 5 secondes pour l'(alter)natif.
Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même chose concernant la méthode SQLTable ? Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les données de ton select. Par contre je pense que l'accès natif de l'éditeur effectue des requetes par paquet. Si c'est le cas, je comprends la différence des temps de réponses.
J'aimerais si possible éviter d'utiliser les deux accès dans la même appli, mais si je n'ai pas le choix, je me résoudrais à le faire.
Je ne vois pas d'inconvénient à "marier" les deux dans ton application si ce n'est 2 connexions à la base.
Avez vous une soluce?
Gilles.
Emmanuel
> Hello.
Bonjour Gilles,
Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable
out de procédure stockée??
J'ai essayé avec Oracle4WD, ca marche très bien, mais étant donné que
mon projet utilise bcp l'instruction SQLTable et que la version
"PCSoft" est bcp bcp plus rapide (j'ai testé sur une requête qui
ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif,
et 5 secondes pour l'(alter)natif.
Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même chose
concernant la méthode SQLTable ?
Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les données
de ton select. Par contre je pense que l'accès natif de l'éditeur effectue
des requetes par paquet. Si c'est le cas, je comprends la différence des
temps de réponses.
J'aimerais si possible éviter d'utiliser les deux accès dans la même
appli, mais si je n'ai pas le choix, je me résoudrais à le faire.
Je ne vois pas d'inconvénient à "marier" les deux dans ton application si ce
n'est 2 connexions à la base.
Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable out de procédure stockée??
J'ai essayé avec Oracle4WD, ca marche très bien, mais étant donné que mon projet utilise bcp l'instruction SQLTable et que la version "PCSoft" est bcp bcp plus rapide (j'ai testé sur une requête qui ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif, et 5 secondes pour l'(alter)natif.
Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même chose concernant la méthode SQLTable ? Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les données de ton select. Par contre je pense que l'accès natif de l'éditeur effectue des requetes par paquet. Si c'est le cas, je comprends la différence des temps de réponses.
J'aimerais si possible éviter d'utiliser les deux accès dans la même appli, mais si je n'ai pas le choix, je me résoudrais à le faire.
Je ne vois pas d'inconvénient à "marier" les deux dans ton application si ce n'est 2 connexions à la base.
Avez vous une soluce?
Gilles.
Emmanuel
Gilles G.
In article <bu0qop$fp5$, says...
> Hello. Bonjour Gilles,
> Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable > out de procédure stockée?? > ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif, > et 5 secondes pour l'(alter)natif. Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même chose concernant la méthode SQLTable ? Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les données de ton select. Par contre je pense que l'accès natif de l'éditeur effectue des requetes par paquet. Si c'est le cas, je comprends la différence des temps de réponses.
Oui, c'est le cas. Si j'effectuais un remplissage de table manuel, il n'est pas à douter que les performances seraient du même acabit.
Vous n'envisagez pas de faire évoluer Oracle4WD pour gérer le SQLTable de la même manière?
Ca serait vraiment génial, parce que leur accès natif, il est bien gentil, mais non content d'être incompatible à chaque changement de release, il est mal documenté.
> J'aimerais si possible éviter d'utiliser les deux accès dans la même > appli, mais si je n'ai pas le choix, je me résoudrais à le faire. Je ne vois pas d'inconvénient à "marier" les deux dans ton application si ce n'est 2 connexions à la base.
Question de "style" ;) Mais c'est comme ça que ça va finir en effet.
En fait, c'est pour contourner un truc super bizarre.
Sur les postes DEV on a une requête qui fonctionne sans souci, et qui échoue sur les postes clients.
Elle a la particularité de contenir un lien DBLINK.
La seule explication c'est qu'en mode développement (via l'install de PCSOFT), la DLL est capable de plus qu'en mode déploiement (juste la DLL fournie avec le projet).
On pensait donc contourner le pb via une procédure stockée ;) Mais comme pour récupérer des valeurs, c'est la galère avec l'accès natif (il faut passer par des requête sur DUAL, je trouve ça moche)...
Mais si le DBLINK fonctionne bien avec Oracle4WD, ca sera encore plus simple.
En tout cas, merci de ce boulot remarquable.
In article <bu0qop$fp5$1@reader1.imaginet.fr>, el@netcourrier.com
says...
> Hello.
Bonjour Gilles,
> Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable
> out de procédure stockée??
> ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif,
> et 5 secondes pour l'(alter)natif.
Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même chose
concernant la méthode SQLTable ?
Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les données
de ton select. Par contre je pense que l'accès natif de l'éditeur effectue
des requetes par paquet. Si c'est le cas, je comprends la différence des
temps de réponses.
Oui, c'est le cas.
Si j'effectuais un remplissage de table manuel, il n'est pas à douter
que les performances seraient du même acabit.
Vous n'envisagez pas de faire évoluer Oracle4WD pour gérer le SQLTable
de la même manière?
Ca serait vraiment génial, parce que leur accès natif, il est bien
gentil, mais non content d'être incompatible à chaque changement de
release, il est mal documenté.
> J'aimerais si possible éviter d'utiliser les deux accès dans la même
> appli, mais si je n'ai pas le choix, je me résoudrais à le faire.
Je ne vois pas d'inconvénient à "marier" les deux dans ton application si ce
n'est 2 connexions à la base.
Question de "style" ;)
Mais c'est comme ça que ça va finir en effet.
En fait, c'est pour contourner un truc super bizarre.
Sur les postes DEV on a une requête qui fonctionne sans souci, et qui
échoue sur les postes clients.
Elle a la particularité de contenir un lien DBLINK.
La seule explication c'est qu'en mode développement (via l'install de
PCSOFT), la DLL est capable de plus qu'en mode déploiement (juste la DLL
fournie avec le projet).
On pensait donc contourner le pb via une procédure stockée ;) Mais comme
pour récupérer des valeurs, c'est la galère avec l'accès natif (il faut
passer par des requête sur DUAL, je trouve ça moche)...
Mais si le DBLINK fonctionne bien avec Oracle4WD, ca sera encore plus
simple.
> Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable > out de procédure stockée?? > ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif, > et 5 secondes pour l'(alter)natif. Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même chose concernant la méthode SQLTable ? Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les données de ton select. Par contre je pense que l'accès natif de l'éditeur effectue des requetes par paquet. Si c'est le cas, je comprends la différence des temps de réponses.
Oui, c'est le cas. Si j'effectuais un remplissage de table manuel, il n'est pas à douter que les performances seraient du même acabit.
Vous n'envisagez pas de faire évoluer Oracle4WD pour gérer le SQLTable de la même manière?
Ca serait vraiment génial, parce que leur accès natif, il est bien gentil, mais non content d'être incompatible à chaque changement de release, il est mal documenté.
> J'aimerais si possible éviter d'utiliser les deux accès dans la même > appli, mais si je n'ai pas le choix, je me résoudrais à le faire. Je ne vois pas d'inconvénient à "marier" les deux dans ton application si ce n'est 2 connexions à la base.
Question de "style" ;) Mais c'est comme ça que ça va finir en effet.
En fait, c'est pour contourner un truc super bizarre.
Sur les postes DEV on a une requête qui fonctionne sans souci, et qui échoue sur les postes clients.
Elle a la particularité de contenir un lien DBLINK.
La seule explication c'est qu'en mode développement (via l'install de PCSOFT), la DLL est capable de plus qu'en mode déploiement (juste la DLL fournie avec le projet).
On pensait donc contourner le pb via une procédure stockée ;) Mais comme pour récupérer des valeurs, c'est la galère avec l'accès natif (il faut passer par des requête sur DUAL, je trouve ça moche)...
Mais si le DBLINK fonctionne bien avec Oracle4WD, ca sera encore plus simple.
En tout cas, merci de ce boulot remarquable.
dptn
pour un appel de procédures stockées avec retour de recordset ... personne n'y arrive ?
j'arrive à appeler une fonction, à declencher une procédure avec x paramètres, mais declencher une procédure avec recupération d'enregistrements, toujours pas....
Si quelqu'un à réussi ...
"Gilles G." a écrit dans le message de news:
In article <bu0qop$fp5$, says... > > Hello. > Bonjour Gilles, > > > Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable > > out de procédure stockée?? > > ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif, > > et 5 secondes pour l'(alter)natif. > Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même
chose
> concernant la méthode SQLTable ? > Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les
données
> de ton select. Par contre je pense que l'accès natif de l'éditeur
effectue
> des requetes par paquet. Si c'est le cas, je comprends la différence des > temps de réponses.
Oui, c'est le cas. Si j'effectuais un remplissage de table manuel, il n'est pas à douter que les performances seraient du même acabit.
Vous n'envisagez pas de faire évoluer Oracle4WD pour gérer le SQLTable de la même manière?
Ca serait vraiment génial, parce que leur accès natif, il est bien gentil, mais non content d'être incompatible à chaque changement de release, il est mal documenté.
> > J'aimerais si possible éviter d'utiliser les deux accès dans la même > > appli, mais si je n'ai pas le choix, je me résoudrais à le faire. > Je ne vois pas d'inconvénient à "marier" les deux dans ton application
si ce
> n'est 2 connexions à la base.
Question de "style" ;) Mais c'est comme ça que ça va finir en effet.
En fait, c'est pour contourner un truc super bizarre.
Sur les postes DEV on a une requête qui fonctionne sans souci, et qui échoue sur les postes clients.
Elle a la particularité de contenir un lien DBLINK.
La seule explication c'est qu'en mode développement (via l'install de PCSOFT), la DLL est capable de plus qu'en mode déploiement (juste la DLL fournie avec le projet).
On pensait donc contourner le pb via une procédure stockée ;) Mais comme pour récupérer des valeurs, c'est la galère avec l'accès natif (il faut passer par des requête sur DUAL, je trouve ça moche)...
Mais si le DBLINK fonctionne bien avec Oracle4WD, ca sera encore plus simple.
En tout cas, merci de ce boulot remarquable.
pour un appel de procédures stockées avec retour de recordset ...
personne n'y arrive ?
j'arrive à appeler une fonction,
à declencher une procédure avec x paramètres,
mais declencher une procédure avec recupération d'enregistrements, toujours
pas....
Si quelqu'un à réussi ...
"Gilles G." <debians@yahoo.fr> a écrit dans le message de
news:GFr.1a6e1ad8bea9fc25989725@News.Individual.NET...
In article <bu0qop$fp5$1@reader1.imaginet.fr>, el@netcourrier.com
says...
> > Hello.
> Bonjour Gilles,
>
> > Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable
> > out de procédure stockée??
> > ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif,
> > et 5 secondes pour l'(alter)natif.
> Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même
chose
> concernant la méthode SQLTable ?
> Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les
données
> de ton select. Par contre je pense que l'accès natif de l'éditeur
effectue
> des requetes par paquet. Si c'est le cas, je comprends la différence des
> temps de réponses.
Oui, c'est le cas.
Si j'effectuais un remplissage de table manuel, il n'est pas à douter
que les performances seraient du même acabit.
Vous n'envisagez pas de faire évoluer Oracle4WD pour gérer le SQLTable
de la même manière?
Ca serait vraiment génial, parce que leur accès natif, il est bien
gentil, mais non content d'être incompatible à chaque changement de
release, il est mal documenté.
> > J'aimerais si possible éviter d'utiliser les deux accès dans la même
> > appli, mais si je n'ai pas le choix, je me résoudrais à le faire.
> Je ne vois pas d'inconvénient à "marier" les deux dans ton application
si ce
> n'est 2 connexions à la base.
Question de "style" ;)
Mais c'est comme ça que ça va finir en effet.
En fait, c'est pour contourner un truc super bizarre.
Sur les postes DEV on a une requête qui fonctionne sans souci, et qui
échoue sur les postes clients.
Elle a la particularité de contenir un lien DBLINK.
La seule explication c'est qu'en mode développement (via l'install de
PCSOFT), la DLL est capable de plus qu'en mode déploiement (juste la DLL
fournie avec le projet).
On pensait donc contourner le pb via une procédure stockée ;) Mais comme
pour récupérer des valeurs, c'est la galère avec l'accès natif (il faut
passer par des requête sur DUAL, je trouve ça moche)...
Mais si le DBLINK fonctionne bien avec Oracle4WD, ca sera encore plus
simple.
pour un appel de procédures stockées avec retour de recordset ... personne n'y arrive ?
j'arrive à appeler une fonction, à declencher une procédure avec x paramètres, mais declencher une procédure avec recupération d'enregistrements, toujours pas....
Si quelqu'un à réussi ...
"Gilles G." a écrit dans le message de news:
In article <bu0qop$fp5$, says... > > Hello. > Bonjour Gilles, > > > Pour ceux qui l'utilisent, y a t il un moyen de récupérer une variable > > out de procédure stockée?? > > ramène environ 3000 enregistrement, c'est 0.5 secondes pour le natif, > > et 5 secondes pour l'(alter)natif. > Merci d'utiliser notre accès. Par contre, es-tu sur de comparé la même
chose
> concernant la méthode SQLTable ? > Le SQLTable de Oracle4WD est une requete qui te renvoie TOUTES les
données
> de ton select. Par contre je pense que l'accès natif de l'éditeur
effectue
> des requetes par paquet. Si c'est le cas, je comprends la différence des > temps de réponses.
Oui, c'est le cas. Si j'effectuais un remplissage de table manuel, il n'est pas à douter que les performances seraient du même acabit.
Vous n'envisagez pas de faire évoluer Oracle4WD pour gérer le SQLTable de la même manière?
Ca serait vraiment génial, parce que leur accès natif, il est bien gentil, mais non content d'être incompatible à chaque changement de release, il est mal documenté.
> > J'aimerais si possible éviter d'utiliser les deux accès dans la même > > appli, mais si je n'ai pas le choix, je me résoudrais à le faire. > Je ne vois pas d'inconvénient à "marier" les deux dans ton application
si ce
> n'est 2 connexions à la base.
Question de "style" ;) Mais c'est comme ça que ça va finir en effet.
En fait, c'est pour contourner un truc super bizarre.
Sur les postes DEV on a une requête qui fonctionne sans souci, et qui échoue sur les postes clients.
Elle a la particularité de contenir un lien DBLINK.
La seule explication c'est qu'en mode développement (via l'install de PCSOFT), la DLL est capable de plus qu'en mode déploiement (juste la DLL fournie avec le projet).
On pensait donc contourner le pb via une procédure stockée ;) Mais comme pour récupérer des valeurs, c'est la galère avec l'accès natif (il faut passer par des requête sur DUAL, je trouve ça moche)...
Mais si le DBLINK fonctionne bien avec Oracle4WD, ca sera encore plus simple.
En tout cas, merci de ce boulot remarquable.
elecoest
bonsoir dptn,
pour un appel de procédures stockées avec retour de recordset ... personne n'y arrive ?
Tout d'abord, une question : avec quel accès natif essaies-tu de faire cela ?
j'arrive à appeler une fonction, à declencher une procédure avec x paramètres,
SI PAS Oracle4WD:mySQLCall(2,"DBName(:1, :2)") ALORS Info(Oracle4WD:mySQLGetErrorMessage()) SINON Info(pajoute, pname, "pname := pajout ||' ' ||dbms_standard.database_name;") ; FIN
Oracle4WD:mySQLFerme(2)
mais declencher une procédure avec recupération d'enregistrements,
toujours
pas....
Ce n'est pas aussi que cela :-(
Si quelqu'un à réussi ...
Pour le moment la fonctionnalité en mode recordset n'est pas prévue avec Oracle4WD. Je vois ce qu'il faut faire, mais pour le moment je cherche plus à gagner en homogénéité des accès natifs. Peut-etre que d'ici juillet, j'aurai plus de billes.
Par contre et cela n'engage QUE moi, c'est un processus dérivé du monde VB, ODBC & cie. Avec Oracle, tu as un curseur, tu lis ce curseur. Pas la peine de passer par une P/S.
Manu sql4wd.rbesset.net
bonsoir dptn,
pour un appel de procédures stockées avec retour de recordset ...
personne n'y arrive ?
Tout d'abord, une question : avec quel accès natif essaies-tu de faire cela
?
j'arrive à appeler une fonction,
à declencher une procédure avec x paramètres,
SI PAS Oracle4WD:mySQLCall(2,"DBName(:1, :2)") ALORS
Info(Oracle4WD:mySQLGetErrorMessage())
SINON
Info(pajoute, pname, "pname := pajout ||' '
||dbms_standard.database_name;") ;
FIN
Oracle4WD:mySQLFerme(2)
mais declencher une procédure avec recupération d'enregistrements,
toujours
pas....
Ce n'est pas aussi que cela :-(
Si quelqu'un à réussi ...
Pour le moment la fonctionnalité en mode recordset n'est pas prévue avec
Oracle4WD. Je vois ce qu'il faut faire, mais pour le moment je cherche plus
à gagner en homogénéité des accès natifs. Peut-etre que d'ici juillet,
j'aurai plus de billes.
Par contre et cela n'engage QUE moi, c'est un processus dérivé du monde VB,
ODBC & cie. Avec Oracle, tu as un curseur, tu lis ce curseur. Pas la peine
de passer par une P/S.
SI PAS Oracle4WD:mySQLCall(2,"DBName(:1, :2)") ALORS Info(Oracle4WD:mySQLGetErrorMessage()) SINON Info(pajoute, pname, "pname := pajout ||' ' ||dbms_standard.database_name;") ; FIN
Oracle4WD:mySQLFerme(2)
mais declencher une procédure avec recupération d'enregistrements,
toujours
pas....
Ce n'est pas aussi que cela :-(
Si quelqu'un à réussi ...
Pour le moment la fonctionnalité en mode recordset n'est pas prévue avec Oracle4WD. Je vois ce qu'il faut faire, mais pour le moment je cherche plus à gagner en homogénéité des accès natifs. Peut-etre que d'ici juillet, j'aurai plus de billes.
Par contre et cela n'engage QUE moi, c'est un processus dérivé du monde VB, ODBC & cie. Avec Oracle, tu as un curseur, tu lis ce curseur. Pas la peine de passer par une P/S.
