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
Roumegou Eric
Gilles G. a utilisé son clavier pour écrire :
Hello.
Le bug est remonté chez PCSOFT, la DLL Native Oracle est incapable de faire une requête sur un DBLINK.
Oui c'est vrai, cela m'était arrivé en 5.5 et accès natif pcsoft. Il fallait faire des sqlchangeconnexion.
Sans Oracle4WD (que je n'ai utilisé qu'à cet effet, hélas à cause du SQLTable), j'aurais été bien bloqué ;)
Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ? Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
Merci à la team ;)
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
Gilles G. a utilisé son clavier pour écrire :
Hello.
Le bug est remonté chez PCSOFT, la DLL Native Oracle est incapable de
faire une requête sur un DBLINK.
Oui c'est vrai, cela m'était arrivé en 5.5 et accès natif pcsoft.
Il fallait faire des sqlchangeconnexion.
Sans Oracle4WD (que je n'ai utilisé qu'à cet effet, hélas à cause du
SQLTable), j'aurais été bien bloqué ;)
Je n'ai plus utilisé SQLTable depuis très très longtemps.
Pourquoi ?
Dés que la table évolue, ou que l'on veut changer la disposition des
colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on
veut rajouter des colonnes calculées etc ... c'est la m...
Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
Merci à la team ;)
--
Eric Roumegou
http://cerbermail.com/?Wk2D8D62KI
(cliquez sur le lien ci-dessus pour me contacter en privé)
Le bug est remonté chez PCSOFT, la DLL Native Oracle est incapable de faire une requête sur un DBLINK.
Oui c'est vrai, cela m'était arrivé en 5.5 et accès natif pcsoft. Il fallait faire des sqlchangeconnexion.
Sans Oracle4WD (que je n'ai utilisé qu'à cet effet, hélas à cause du SQLTable), j'aurais été bien bloqué ;)
Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ? Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
Merci à la team ;)
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
Gilles G.
In article , says...
Gilles G. a utilisé son clavier pour écrire : > Hello. > > Le bug est remonté chez PCSOFT, la DLL Native Oracle est incapable de > faire une requête sur un DBLINK.
Oui c'est vrai, cela m'était arrivé en 5.5 et accès natif pcsoft. Il fallait faire des sqlchangeconnexion. > Sans Oracle4WD (que je n'ai utilisé qu'à cet effet, hélas à cause du > SQLTable), j'aurais été bien bloqué ;) > Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ?
Quand tu veux charger le résultat (milliers de lignes) d'une requête dans une table, avec SQLTable, c'est quasi instantané. Si tu lis enregistrement par enregistrement, c'est très long. (Le SQLTAble PCSoft doit certainement se baser sur un curseur oracle).
Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup. Mais je suis tout ouï à des contre arguments ...
Peut être en développement, mais le temps de développement, c'est dérisoire à côté d'un client qui gueule parce que c'est trop lent ;)
Et pour avoir comparé les deux sur 3000 lignes de longueur correcte (chaines, etc...), SQLTable PCSoft : environ 10 fois plus rapide que le SQLTable Oracle4WD (qui se contente de faire un fetch de chaque ligne et de remplir la table ligne à ligne).
In article <mesnews.83147d41.cf6d9af7.82.4556@fin.msg>,
Utilisezlelien@fin.msg says...
Gilles G. a utilisé son clavier pour écrire :
> Hello.
>
> Le bug est remonté chez PCSOFT, la DLL Native Oracle est incapable de
> faire une requête sur un DBLINK.
Oui c'est vrai, cela m'était arrivé en 5.5 et accès natif pcsoft.
Il fallait faire des sqlchangeconnexion.
> Sans Oracle4WD (que je n'ai utilisé qu'à cet effet, hélas à cause du
> SQLTable), j'aurais été bien bloqué ;)
> Je n'ai plus utilisé SQLTable depuis très très longtemps.
Pourquoi ?
Quand tu veux charger le résultat (milliers de lignes) d'une requête
dans une table, avec SQLTable, c'est quasi instantané.
Si tu lis enregistrement par enregistrement, c'est très long.
(Le SQLTAble PCSoft doit certainement se baser sur un curseur oracle).
Dés que la table évolue, ou que l'on veut changer la disposition des
colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on
veut rajouter des colonnes calculées etc ... c'est la m...
Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
Peut être en développement, mais le temps de développement, c'est
dérisoire à côté d'un client qui gueule parce que c'est trop lent ;)
Et pour avoir comparé les deux sur 3000 lignes de longueur correcte
(chaines, etc...), SQLTable PCSoft : environ 10 fois plus rapide que le
SQLTable Oracle4WD (qui se contente de faire un fetch de chaque ligne et
de remplir la table ligne à ligne).
Gilles G. a utilisé son clavier pour écrire : > Hello. > > Le bug est remonté chez PCSOFT, la DLL Native Oracle est incapable de > faire une requête sur un DBLINK.
Oui c'est vrai, cela m'était arrivé en 5.5 et accès natif pcsoft. Il fallait faire des sqlchangeconnexion. > Sans Oracle4WD (que je n'ai utilisé qu'à cet effet, hélas à cause du > SQLTable), j'aurais été bien bloqué ;) > Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ?
Quand tu veux charger le résultat (milliers de lignes) d'une requête dans une table, avec SQLTable, c'est quasi instantané. Si tu lis enregistrement par enregistrement, c'est très long. (Le SQLTAble PCSoft doit certainement se baser sur un curseur oracle).
Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup. Mais je suis tout ouï à des contre arguments ...
Peut être en développement, mais le temps de développement, c'est dérisoire à côté d'un client qui gueule parce que c'est trop lent ;)
Et pour avoir comparé les deux sur 3000 lignes de longueur correcte (chaines, etc...), SQLTable PCSoft : environ 10 fois plus rapide que le SQLTable Oracle4WD (qui se contente de faire un fetch de chaque ligne et de remplir la table ligne à ligne).
Manu
> Et pour avoir comparé les deux sur 3000 lignes de longueur correcte (chaines, etc...), SQLTable PCSoft : environ 10 fois plus rapide que le SQLTable Oracle4WD (qui se contente de faire un fetch de chaque ligne et de remplir la table ligne à ligne).
Désolé mais ce n'est pas tout à fait cela ;-)
Oracle4WD gère ses propres curseurs (un pour chaque requete) en interne à la DLL. A chaque lecture il lit 1000 lignes d'un coup qu'il charge dans un tableau. A chaque fetch Windev, on va lire dans le tableau de la dll.
Ce qui est ennuyeux c'est que Oracle4WD à été customisé pour compatibilité avec SQLManagerX (gestion de l'ordre HPrécédent :-(, des limites basses et hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un artifice qui faire perdre un peu de temps par rapport à une utilisation standard des curseurs (boucle de lecture).
Voilà vous avez découvert mon secret .
Manu
> Et pour avoir comparé les deux sur 3000 lignes de longueur correcte
(chaines, etc...), SQLTable PCSoft : environ 10 fois plus rapide que le
SQLTable Oracle4WD (qui se contente de faire un fetch de chaque ligne et
de remplir la table ligne à ligne).
Désolé mais ce n'est pas tout à fait cela ;-)
Oracle4WD gère ses propres curseurs (un pour chaque requete) en interne à la
DLL. A chaque lecture il lit 1000 lignes d'un coup qu'il charge dans un
tableau. A chaque fetch Windev, on va lire dans le tableau de la dll.
Ce qui est ennuyeux c'est que Oracle4WD à été customisé pour compatibilité
avec SQLManagerX (gestion de l'ordre HPrécédent :-(, des limites basses et
hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un artifice
qui faire perdre un peu de temps par rapport à une utilisation standard des
curseurs (boucle de lecture).
> Et pour avoir comparé les deux sur 3000 lignes de longueur correcte (chaines, etc...), SQLTable PCSoft : environ 10 fois plus rapide que le SQLTable Oracle4WD (qui se contente de faire un fetch de chaque ligne et de remplir la table ligne à ligne).
Désolé mais ce n'est pas tout à fait cela ;-)
Oracle4WD gère ses propres curseurs (un pour chaque requete) en interne à la DLL. A chaque lecture il lit 1000 lignes d'un coup qu'il charge dans un tableau. A chaque fetch Windev, on va lire dans le tableau de la dll.
Ce qui est ennuyeux c'est que Oracle4WD à été customisé pour compatibilité avec SQLManagerX (gestion de l'ordre HPrécédent :-(, des limites basses et hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un artifice qui faire perdre un peu de temps par rapport à une utilisation standard des curseurs (boucle de lecture).
Voilà vous avez découvert mon secret .
Manu
Fabrice Burghgraeve
salut.
"Roumegou Eric" a écrit dans le message de news:
Gilles G. a utilisé son clavier pour écrire :
(...)
Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ? Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
mon contre argument est que c'est pas si complique que ca de changer la requete qui est avant le sqltable. Par exemple, t'as une requete : select c1,c2,c3 from .... sqltable
dans ta table (je suppose que tu parles de la table dans l'editeur windev, pas celle de la base de donnees), tu decides de rajouter une colonne c2bis entre c2 et c3, qui ne correspond a rien dans la base. ta requete deviens alors : select c1,c2,'',c3 from ...
c'est si complique que ca ??? ;-)
un contre argument a mon contre argument : il y a un truc qui est vraiment vraiment mal foutu avec sqltable : il ne verifie rien. Par exemple : tu peux faire un sqltable d'une requete qui te reponds 10 colonnes et mettre le resultat dans une table a 2 colonne, ou inversement. IL ne verifie pas non plus les types des colonnes ...
bref, meme genre de probleme qu'avec sqllitcol qui verifie queudalle, meme pas que tu lises une colonne qui existe... exemple : sqlexec ("select c1 from ...",nom_requete); tantque sqlfetch(nom_requete) sqllitcol(nom_requete,1); sqllitcol(nom_requete, 2) sqllitcol("trilili", 12) fin
pas de message d'erreur a l'execution la dedans... aucun controle... des heures perdues a chercher ou est-ce que tu t'es planté a mettre un 2 a la place d'un trois ou avoir oublie une lettre dans le nom de la requete.
Pour continuer dans le bruit et rester dans le sujet du thread, ca montre bien que c'est pas parce que c'est plus cher que c'est mieux ...
-- Fabrice Burghgraeve Computer & Services suivez ce lien pour me repondre en prive : http://cerbermail.com/?I3GMPRuXDD
salut.
"Roumegou Eric" <Utilisezlelien@fin.msg> a écrit dans le message de
news:mesnews.83147d41.cf6d9af7.82.4556@fin.msg...
Gilles G. a utilisé son clavier pour écrire :
(...)
Je n'ai plus utilisé SQLTable depuis très très longtemps.
Pourquoi ?
Dés que la table évolue, ou que l'on veut changer la disposition des
colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on
veut rajouter des colonnes calculées etc ... c'est la m...
Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
mon contre argument est que c'est pas si complique que ca de changer la
requete qui est avant le sqltable.
Par exemple, t'as une requete :
select c1,c2,c3 from ....
sqltable
dans ta table (je suppose que tu parles de la table dans l'editeur windev,
pas celle de la base de donnees),
tu decides de rajouter une colonne c2bis entre c2 et c3, qui ne correspond a
rien dans la base.
ta requete deviens alors :
select c1,c2,'',c3 from ...
c'est si complique que ca ??? ;-)
un contre argument a mon contre argument :
il y a un truc qui est vraiment vraiment mal foutu avec sqltable :
il ne verifie rien.
Par exemple : tu peux faire un sqltable d'une requete qui te reponds 10
colonnes et mettre le resultat dans une table a 2 colonne, ou inversement.
IL ne verifie pas non plus les types des colonnes ...
bref, meme genre de probleme qu'avec sqllitcol qui verifie queudalle, meme
pas que tu lises une colonne qui existe...
exemple :
sqlexec ("select c1 from ...",nom_requete);
tantque sqlfetch(nom_requete)
sqllitcol(nom_requete,1);
sqllitcol(nom_requete, 2)
sqllitcol("trilili", 12)
fin
pas de message d'erreur a l'execution la dedans... aucun controle... des
heures perdues a chercher ou est-ce que tu t'es planté a mettre un 2 a la
place d'un trois ou avoir oublie une lettre dans le nom de la requete.
Pour continuer dans le bruit et rester dans le sujet du thread, ca montre
bien que c'est pas parce que c'est plus cher que c'est mieux ...
--
Fabrice Burghgraeve
Computer & Services
suivez ce lien pour me repondre en prive :
http://cerbermail.com/?I3GMPRuXDD
Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ? Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
mon contre argument est que c'est pas si complique que ca de changer la requete qui est avant le sqltable. Par exemple, t'as une requete : select c1,c2,c3 from .... sqltable
dans ta table (je suppose que tu parles de la table dans l'editeur windev, pas celle de la base de donnees), tu decides de rajouter une colonne c2bis entre c2 et c3, qui ne correspond a rien dans la base. ta requete deviens alors : select c1,c2,'',c3 from ...
c'est si complique que ca ??? ;-)
un contre argument a mon contre argument : il y a un truc qui est vraiment vraiment mal foutu avec sqltable : il ne verifie rien. Par exemple : tu peux faire un sqltable d'une requete qui te reponds 10 colonnes et mettre le resultat dans une table a 2 colonne, ou inversement. IL ne verifie pas non plus les types des colonnes ...
bref, meme genre de probleme qu'avec sqllitcol qui verifie queudalle, meme pas que tu lises une colonne qui existe... exemple : sqlexec ("select c1 from ...",nom_requete); tantque sqlfetch(nom_requete) sqllitcol(nom_requete,1); sqllitcol(nom_requete, 2) sqllitcol("trilili", 12) fin
pas de message d'erreur a l'execution la dedans... aucun controle... des heures perdues a chercher ou est-ce que tu t'es planté a mettre un 2 a la place d'un trois ou avoir oublie une lettre dans le nom de la requete.
Pour continuer dans le bruit et rester dans le sujet du thread, ca montre bien que c'est pas parce que c'est plus cher que c'est mieux ...
-- Fabrice Burghgraeve Computer & Services suivez ce lien pour me repondre en prive : http://cerbermail.com/?I3GMPRuXDD
Roumegou Eric
Fabrice Burghgraeve avait énoncé :
salut.
"Roumegou Eric" a écrit dans le message de news:
Gilles G. a utilisé son clavier pour écrire : (...) Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ? Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
mon contre argument est que c'est pas si complique que ca de changer la requete qui est avant le sqltable. Par exemple, t'as une requete : select c1,c2,c3 from .... sqltable
dans ta table (je suppose que tu parles de la table dans l'editeur windev, pas celle de la base de donnees), tu decides de rajouter une colonne c2bis entre c2 et c3, qui ne correspond a rien dans la base. ta requete deviens alors : select c1,c2,'',c3 from ...
c'est si complique que ca ??? ;-)
Non, mais cela ne me plait pas :-) J'ai horreur des astuces, petits trucs futés et bien cachés De toutes façon, c'est un prog qui m'écrit le code; donc il pisse de la ligne pour moi et il a intérêt de pisser droit ;-)
un contre argument a mon contre argument : il y a un truc qui est vraiment vraiment mal foutu avec sqltable : il ne verifie rien. Par exemple : tu peux faire un sqltable d'une requete qui te reponds 10 colonnes et mettre le resultat dans une table a 2 colonne, ou inversement. IL ne verifie pas non plus les types des colonnes ...
bref, meme genre de probleme qu'avec sqllitcol qui verifie queudalle, meme pas que tu lises une colonne qui existe... exemple : sqlexec ("select c1 from ...",nom_requete); tantque sqlfetch(nom_requete) sqllitcol(nom_requete,1); sqllitcol(nom_requete, 2)
C'est pour cela que j'aime mieux NumCol++;monchp=sqllitcol(nom_requete, NumCol). Plus facile de chambouler l'ordre des champs.
sqllitcol("trilili", 12) fin
pas de message d'erreur a l'execution la dedans... aucun controle... des heures perdues a chercher ou est-ce que tu t'es planté a mettre un 2 a la place d'un trois ou avoir oublie une lettre dans le nom de la requete.
Pour continuer dans le bruit et rester dans le sujet du thread, ca montre bien que c'est pas parce que c'est plus cher que c'est mieux ...
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
Fabrice Burghgraeve avait énoncé :
salut.
"Roumegou Eric" <Utilisezlelien@fin.msg> a écrit dans le message de
news:mesnews.83147d41.cf6d9af7.82.4556@fin.msg...
Gilles G. a utilisé son clavier pour écrire : (...)
Je n'ai plus utilisé SQLTable depuis très très longtemps.
Pourquoi ?
Dés que la table évolue, ou que l'on veut changer la disposition des
colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on
veut rajouter des colonnes calculées etc ... c'est la m...
Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
mon contre argument est que c'est pas si complique que ca de changer la
requete qui est avant le sqltable.
Par exemple, t'as une requete :
select c1,c2,c3 from ....
sqltable
dans ta table (je suppose que tu parles de la table dans l'editeur windev,
pas celle de la base de donnees),
tu decides de rajouter une colonne c2bis entre c2 et c3, qui ne correspond a
rien dans la base.
ta requete deviens alors :
select c1,c2,'',c3 from ...
c'est si complique que ca ??? ;-)
Non, mais cela ne me plait pas :-)
J'ai horreur des astuces, petits trucs futés et bien cachés
De toutes façon, c'est un prog qui m'écrit le code; donc il pisse de la
ligne pour moi et il a intérêt de pisser droit ;-)
un contre argument a mon contre argument :
il y a un truc qui est vraiment vraiment mal foutu avec sqltable :
il ne verifie rien.
Par exemple : tu peux faire un sqltable d'une requete qui te reponds 10
colonnes et mettre le resultat dans une table a 2 colonne, ou inversement.
IL ne verifie pas non plus les types des colonnes ...
bref, meme genre de probleme qu'avec sqllitcol qui verifie queudalle, meme
pas que tu lises une colonne qui existe...
exemple :
sqlexec ("select c1 from ...",nom_requete);
tantque sqlfetch(nom_requete)
sqllitcol(nom_requete,1);
sqllitcol(nom_requete, 2)
C'est pour cela que j'aime mieux NumCol++;monchp=sqllitcol(nom_requete,
NumCol). Plus facile de chambouler l'ordre des champs.
sqllitcol("trilili", 12)
fin
pas de message d'erreur a l'execution la dedans... aucun controle... des
heures perdues a chercher ou est-ce que tu t'es planté a mettre un 2 a la
place d'un trois ou avoir oublie une lettre dans le nom de la requete.
Pour continuer dans le bruit et rester dans le sujet du thread, ca montre
bien que c'est pas parce que c'est plus cher que c'est mieux ...
--
Eric Roumegou
http://cerbermail.com/?Wk2D8D62KI
(cliquez sur le lien ci-dessus pour me contacter en privé)
Gilles G. a utilisé son clavier pour écrire : (...) Je n'ai plus utilisé SQLTable depuis très très longtemps. Pourquoi ? Dés que la table évolue, ou que l'on veut changer la disposition des colonnes, ou que l'on rajoute ou supprime des colonnes, ou que l'on veut rajouter des colonnes calculées etc ... c'est la m... Et ce qu'on a économisé comme temps au départ, on le perd d'un coup.
Mais je suis tout ouï à des contre arguments ...
mon contre argument est que c'est pas si complique que ca de changer la requete qui est avant le sqltable. Par exemple, t'as une requete : select c1,c2,c3 from .... sqltable
dans ta table (je suppose que tu parles de la table dans l'editeur windev, pas celle de la base de donnees), tu decides de rajouter une colonne c2bis entre c2 et c3, qui ne correspond a rien dans la base. ta requete deviens alors : select c1,c2,'',c3 from ...
c'est si complique que ca ??? ;-)
Non, mais cela ne me plait pas :-) J'ai horreur des astuces, petits trucs futés et bien cachés De toutes façon, c'est un prog qui m'écrit le code; donc il pisse de la ligne pour moi et il a intérêt de pisser droit ;-)
un contre argument a mon contre argument : il y a un truc qui est vraiment vraiment mal foutu avec sqltable : il ne verifie rien. Par exemple : tu peux faire un sqltable d'une requete qui te reponds 10 colonnes et mettre le resultat dans une table a 2 colonne, ou inversement. IL ne verifie pas non plus les types des colonnes ...
bref, meme genre de probleme qu'avec sqllitcol qui verifie queudalle, meme pas que tu lises une colonne qui existe... exemple : sqlexec ("select c1 from ...",nom_requete); tantque sqlfetch(nom_requete) sqllitcol(nom_requete,1); sqllitcol(nom_requete, 2)
C'est pour cela que j'aime mieux NumCol++;monchp=sqllitcol(nom_requete, NumCol). Plus facile de chambouler l'ordre des champs.
sqllitcol("trilili", 12) fin
pas de message d'erreur a l'execution la dedans... aucun controle... des heures perdues a chercher ou est-ce que tu t'es planté a mettre un 2 a la place d'un trois ou avoir oublie une lettre dans le nom de la requete.
Pour continuer dans le bruit et rester dans le sujet du thread, ca montre bien que c'est pas parce que c'est plus cher que c'est mieux ...
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
Gilles G.
In article <bu8n6u$oc3$, says...
> Et pour avoir comparé les deux sur 3000 lignes de longueur correcte hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un artifice qui faire perdre un peu de temps par rapport à une utilisation standard des curseurs (boucle de lecture).
C'est dommage, c'est très bloquant pour ce genre de fonctionnalité, les perfs sont très fortement dégradées.
In article <bu8n6u$oc3$1@reader1.imaginet.fr>, el@netcourrier.com
says...
> Et pour avoir comparé les deux sur 3000 lignes de longueur correcte
hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un artifice
qui faire perdre un peu de temps par rapport à une utilisation standard des
curseurs (boucle de lecture).
C'est dommage, c'est très bloquant pour ce genre de fonctionnalité, les
perfs sont très fortement dégradées.
> Et pour avoir comparé les deux sur 3000 lignes de longueur correcte hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un artifice qui faire perdre un peu de temps par rapport à une utilisation standard des curseurs (boucle de lecture).
C'est dommage, c'est très bloquant pour ce genre de fonctionnalité, les perfs sont très fortement dégradées.
elecoest
> > > Et pour avoir comparé les deux sur 3000 lignes de longueur correcte > > hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un
artifice
> qui faire perdre un peu de temps par rapport à une utilisation standard
des
> curseurs (boucle de lecture).
C'est dommage, c'est très bloquant pour ce genre de fonctionnalité, les perfs sont très fortement dégradées.
Je vais voir pour gérer un niveau de compatibilité dans ma DLL : - Accès en mode natif : uniquement les méthodes exec (litpremier), fetch (suivant) - Accès en mode GestionSQL : reste à voir les besoins exacts - Accès en mode SQLManagerX
Je vous tiendrai au courant
Manu
> > > Et pour avoir comparé les deux sur 3000 lignes de longueur correcte
>
> hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un
artifice
> qui faire perdre un peu de temps par rapport à une utilisation standard
des
> curseurs (boucle de lecture).
C'est dommage, c'est très bloquant pour ce genre de fonctionnalité, les
perfs sont très fortement dégradées.
Je vais voir pour gérer un niveau de compatibilité dans ma DLL :
- Accès en mode natif : uniquement les méthodes exec (litpremier), fetch
(suivant)
- Accès en mode GestionSQL : reste à voir les besoins exacts
- Accès en mode SQLManagerX
> > > Et pour avoir comparé les deux sur 3000 lignes de longueur correcte > > hautes à la MySQL). Donc pour gérer cela nous avons du ajouter un
artifice
> qui faire perdre un peu de temps par rapport à une utilisation standard
des
> curseurs (boucle de lecture).
C'est dommage, c'est très bloquant pour ce genre de fonctionnalité, les perfs sont très fortement dégradées.
Je vais voir pour gérer un niveau de compatibilité dans ma DLL : - Accès en mode natif : uniquement les méthodes exec (litpremier), fetch (suivant) - Accès en mode GestionSQL : reste à voir les besoins exacts - Accès en mode SQLManagerX
