|
| Iniciado por dirk_nospam, 12,nov. 2004 12:19 - 5 respuestas |
| |
| | | |
|
| |
| Publicado el 12,noviembre 2004 - 12:19 |
Bjr,
Est-il possible d'affecter lors d'une requete SQLEXEC le nom des champs de
la table SQL par programmation sans avoir besoin de les encoder manuellement
?
Merci d'avance
Dirk |
| |
| |
| | | |
|
| | |
| |
| Publicado el 12,noviembre 2004 - 15:45 |
Je ne vois pas le sens de ta question vu que l'accès natif de SQL permet de nous éviter d'utiliser la commande SQLEXEC qui est plus utile pour lire une base via ODBC.
Il suffit de mettre ta table SQL dans ton analyse et tu l'exploites comme une table hyperfile. C'est nettement plus rapide.
La seule fois où on n'a pas pu utiliser les commandes Windev (version 7.5), ce fut sur certain fichier dont les clés contenaient du binaire ou des champs chargés avec la valeur .NULL.
La base, Sage pour ne pas la nommer, ne voulait pas de champ à blanc où à zéro. Il fait un contrôle dessus, enfin sur certain fichier. Pour ces cas là, on est passé par les commandes SQL Insert et Update et bien entendu il a fallu saisir les champs à la mimine.
Romain |
| |
| |
| | | |
|
| | |
| |
| Publicado el 12,noviembre 2004 - 18:08 |
La requête passé à SQLExec l'est sous la forme d'une chaine de charactères, il est tout à fait possible de la créer dynamiquement. C'est ce que je fais dans une application, la requête est construite en fonction des critères de recherches renseignés par l'utilisateur.
Ce n'est pas avec un accès natif à SQLServer, mais via une connection ODBC, mais celà ne change rien à l'affaire. D'ailleurs, pourquoi utiliser l'accès natif et SQLExec ?
Frédéric. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 15,noviembre 2004 - 15:08 |
D'accord mais si l'on ajoute un cahmp à la table .... je dois modifier mon
logiciel. Actuellement, les 2 peuvent travailler de manière indépendante
Dirk
"Romain Roehrig" <r.roehrig@ador.fr> wrote in message
news:4194b4cb$1@news.pcsoft.fr...
Je ne vois pas le sens de ta question vu que l'accès natif de SQL permet
de nous éviter d'utiliser la commande SQLEXEC qui est plus utile pour lire
une base via ODBC.
> Il suffit de mettre ta table SQL dans ton analyse et tu l'exploites comme
une table hyperfile. C'est nettement plus rapide.
La seule fois où on n'a pas pu utiliser les commandes Windev (version
7.5), ce fut sur certain fichier dont les clés contenaient du binaire ou des
champs chargés avec la valeur .NULL.
> La base, Sage pour ne pas la nommer, ne voulait pas de champ à blanc où à
zéro. Il fait un contrôle dessus, enfin sur certain fichier. Pour ces cas
là, on est passé par les commandes SQL Insert et Update et bien entendu il a
fallu saisir les champs à la mimine.
Romain
|
| |
| |
| | | |
|
| | |
| |
| Publicado el 15,noviembre 2004 - 15:08 |
L'accès natif est bcp plus rapide ....
Dirk
"Frédéric DEMILLY" <f.demilly@pacificpeche.fr> wrote in message
news:4194d661@news.pcsoft.fr...
La requête passé à SQLExec l'est sous la forme d'une chaine de
charactères, il est tout à fait possible de la créer dynamiquement. C'est ce
que je fais dans une application, la requête est construite en fonction des
critères de recherches renseignés par l'utilisateur.
> Ce n'est pas avec un accès natif à SQLServer, mais via une connection
ODBC, mais celà ne change rien à l'affaire. D'ailleurs, pourquoi utiliser
l'accès natif et SQLExec ?
Frédéric.
|
| |
| |
| | | |
|
| | |
| |
| Publicado el 16,noviembre 2004 - 20:22 |
Effectivement l'accès natif est beaucoup plus rapide.
On peut déclarer les champs par programmation. Tout d'abord il faut importer des descriptions de fichier (sans les données) de la base SQL Server dans l'analyse puis utiliser HListeRubrique pour affecter le nom des champs automatiquement. |
| |
| |
| | | |
|
| | | | |
| | |
|