Voila ce que j'ai qui ne passe pas :


le hDeclareExterne passe. En rechanche hExecuteRequeteSQL provoque une erreur "Code erreur : 70199 ##InternalError##" dans WDHF.dll

Ne peut-on exécuter des requêtes sur des fichiers externes ? J'ai du brouillard devant les yeux ou je n'aurias encore testé cela ?

Bonjour,
je viens de tester et chez moi ça fonctionne, à noter que je suis en Wdv9.
Donc bonne chance :)

Bonjour Romu,

Pourquoi encadrer la variable "ssql" alors qu'elle est déclarée comme source de donnée ?

devrait aller tout aussi bien
de plus cSql devrait plutôt être une chaine et nom une source de données!

ATTENTION, il faut quand meme penser à dormir un peu.
ATTENTION au surmenage

Regarde bien son code DrCharly, cSql n'est pas déclaré dans son code ...

R&B : Sauf erreur de ma part HDéclereExterne demande un nom d'alias (chaine) et non une source de données.

Merci Totof de la précision, j'explore cette piste.
Pour info :
WD 7.0 512J (Silc)
Citation :
C'est bien ma veine !

En utilisant non plus une source de donnée mais la chaine utilisée pour la propriété ..Nom dans la description de ce fichier temporaire j'obtient le même résultat.

Note : En revanche le parcours HyperFile classique et tous les ordres hXXX passe à merveille. Seul le SQL me semble interdit avec le fichier décrit en dynamique.

J'ai donc utilisé les parcours HyperFile classique en attendant.

Bonjour Romu,
Pourquoi ne pas passer par les vues ?

... Parce qu'il semblerait que l'âge me gagne.
(un vue pour faire la somme de trois rubriques sur tout le fichier ?).
Merci DrCharly je vais voir de ce coté.

R&B, pourquoi ne passes tu pas en version 7.5 de windev ?

a+

totof

Salut,
Sur ce projet en production, des impératifs ont toujours interrompus nos tentatives de migration.
En effet il s'agit d'un projet conséquent (80 classes, 175 Etats, 320 fenêtre...). Ses tests sont sont particulièrement cruciaux, d'autant que nombre d'entre eux ont été validé par des clients. Il n'est donc pas indiqué de toucher à ce qui est supposé être validé ! La sentence d'une erreur serait extrèmement coûteuse.

NB : nous avons quand même régulièrement "rétro-compilé" le projet. En fait ouvert dans les version successives de WinDev, corrigé les erreurs de compilation et remonté les corrections dans la version 7.0. Le gains est énorme quand on connait les progrès du compilateur. Et la migration est facilitée à chaque tentative.

Sans profiter des nouveautés, le projet est exceptionnellement stable si on considère qu'il est développé avec un outil "Buggué".

En parlant de stabilité, la dernière version de 7.5 est stable (d'après mes tests).
Tu profites de quelques améliorations, notamment une stabilité accru des threads et amélioration de la gestion des requêtes SQL dans windev.
En version 8, les threads sont encore plus stable mais là je ne peux pas garantir qu'il y ait une version exempte de problèmes (Dernière version de windev 8: le groupware développeur ne fonctionne pas correctement et la version d'avant tu risques de perdre du code dans des classes lors d'une recompilation du projet ...).

Je comprend ton problème de passage à la version supérieur, j'ai le même chez mes clients c'est pour celà que nous allons migrer notre application pgi de 5.5 à 7.5 cet été.
J'ai bien pu tester les évolutions du produit dans de nouveaux projets en démarrant en version 7. La version 7 pour moi n'étais pas assez stable, mais la 7.5 est correcte.

a+

totof