je me remets a vous pour quelques petites questions concernant Windev
Je viens de terminer une petite application d'une cinquantaine de
fen=EAtres + des =E9tats.
Celle-ci est bas=E9e exclusivement sur HF en mode local. Elle repr=E9sente
pas mal de temps de d=E9veloppement, mais je l'ai cr=E9=E9e pour "pour
apprendre" Windev.
Au terme de cette applications, il me reste des questions dont je ne
trouve pas vraiment la r=E9ponse, et je m'en remets donc a votre
exp=E9rience.
1)---
Quel est le ph=E9nom=E8ne qui fait pousser des fichiers num=E9rot=E9s dans l=
e
r=E9pertoire de l'application ? J'installe mon application, j'ai un
HcreationSiInexistant(*) dans le code de d=E9marrage et au bout de
quelques temps, je trouve des fichiers : clients.001.FIC / factures.
001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
2) --
je termine aujourd'hui le bouquin "Windev et Windev Mobile de Merise
au Client Serveur ..." et je remarque qu'au chapitre "Client/serveur",
M.Baptiste nous dit de privil=E9gier les requ=EAtes SQL pour am=E9liorer les=
performances de l'application.
Jusque la OK ... je ne me permettrai pas de contrarier ;-)
Par contre en parcourant son code je remarque qu'il utilise des
boucles pour remplir les tables et les combos:
**********************************
Larequete est source de donn=E9es
SI HexecuterequeteSQL(larequete,"Select * From Clients")
HlitPremier(larequte)
Tantque pas hendehors(larequete)
ListeAjoute( ... etc )
HLitSuivant(laRequete)
FIN
**********************************
Donc si je veux passer mon appli en mode C/S je DOIS utiliser ce type
de code ? Alors que deviennent toutes les fonctions si pratique comme
"EcranVersFichier()" ? J'ai un peut de peine a comprendre comment
relier des zones de saisie d'une fen=EAtre a un resultat de requete qui
n'existe pas encore =E9tant donn=E9 que la source de donn=E9e sera
initialis=E9e lors d'un chargement de la fen=EAtre ou le clic d'un
bouton :
**********************************
ssql est une chaine =3D"SELECT * FROM Clients"
HexecuteRequeteSQL(larequete,ssql)
**********************************
Ou alors utilisez vous les requ=EAtes "fichier" (cr=E9=E9es avec l'=E9diteur=
de requ=EAte int=E9gr=E9), mais cela ne risque pas de faire un nombre
impressionnant de requetes.
Ou est-ce qu'il est MIEUX d'utiliser les fonctions SQL en C/S mais que
les fonctions HF sur les fichiers sont utilisables en C/S mais que les
requ=EAtes SQL sont plus optimis=E9es ?
3) ---
Il me reste toujours une vieille habitude de VB, quand je cr=E9e une
source de donn=E9e avec un :
***********************************
RS est une source de donn=E9e
***********************************
Doit-on obligatoirement d=E9truire l'objet une fois celui -ci utilis=E9 ,
en fin de fonction par exemple avec un HAnnuleD=E9claration(RS)
J'esp=E8re que j'ai =E9t=E9 assez clair dans mes explications
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
mat
Bonjour,
wd_newbie wrote:
1)--- Quel est le phénomène qui fait pousser des fichiers numérotés dans le répertoire de l'application ? J'installe mon application, j'ai un HcreationSiInexistant(*) dans le code de démarrage et au bout de quelques temps, je trouve des fichiers : clients.001.FIC / factures. 001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
j'ai remarqué ça seulement avec les fichiers de journaux lors d'un changement de structure, donc une copie de sauvegarde automatique de Windev.
2) --
...
********************************** Larequete est source de données
SI HexecuterequeteSQL(larequete,"Select * From Clients")
HlitPremier(larequte) Tantque pas hendehors(larequete)
ListeAjoute( ... etc )
HLitSuivant(laRequete)
FIN **********************************
Donc si je veux passer mon appli en mode C/S je DOIS utiliser ce type de code ? Alors que deviennent toutes les fonctions si pratique comme "EcranVersFichier()" ?
on ne doit pas, mais le résultat de la requête est entièrement en mémoire vive, donc une boucle est très efficace. On obtient la même chose avec FichierVersTableMémoire, faut tester pour voir ce qui est plus efficace. A part cela j'utilise plutôt une boucle POUR TOUT que je peux également utiliser comme filtre. C'est plus rapide qu'à chaque fois relancer la requête.
EcranVersFichier devrait probablement lire FicherVersEcran, oui mais alors il faut avoir lié la source de données au champ.
J'ai un peut de peine a comprendre comment
relier des zones de saisie d'une fenêtre a un resultat de requete qui n'existe pas encore étant donné que la source de donnée sera initialisée lors d'un chargement de la fenêtre ou le clic d'un bouton :
cela marche bien avec une requête du projet. En utilisant le même nom avec hExecuteRequeteSQL on peut modifier totalement cette requête, on a donc le meilleur des deux mondes: liaison des champs (pour les états dans notre cas), flexibilité des requêtes SQL.
On peut également changer les sources de données/liaisons par programmation.
Je ne fais pas de liaison de requêtes avec les champs de saisie pour la simple raison que la requête ne donne pas de retour si un ajout ou une modification a vraiment pris place (non plus une suppression. La valeur retournée confirme que la requête n'a pas d'erreur). Ceci au moins jusqu'à WD10 que j'utilise, mais je n'ai rien lu que cela aurait changé.
********************************** ssql est une chaine ="SELECT * FROM Clients" HexecuteRequeteSQL(larequete,ssql) **********************************
Ou alors utilisez vous les requêtes "fichier" (créées avec l'éditeur de requête intégré), mais cela ne risque pas de faire un nombre impressionnant de requetes.
il y a des gens qui disent que des requêtes utilisant des sources de données sont plus efficace que les requêtes enregistrées du projet. Je ne l'ai jamais testé, car dans la plupart des cas, j'utilise des requêtes comme source de données pour mes états, donc une source de donnée complique les choses (sauf si les rubriques et champs portent les mêmes noms, alors on peut créer p.ex. un état avec les champs de fichier et dans le code d'ouverture de l'état changer la source de données.
Ou est-ce qu'il est MIEUX d'utiliser les fonctions SQL en C/S mais que les fonctions HF sur les fichiers sont utilisables en C/S mais que les requêtes SQL sont plus optimisées ?
je n'utilise pas HF C/S, mais avec le couple Windev/HF HP cela ne change rien: les requêtes sont plus efficace justement pour des requêtes. Pour les ajouts, modifications et suppressions, j'utilise EcranVersFichier, hAjoute, hModifie et hSupprime. A mon avis ça donne plus de contrôle et facilite la vie avec Windev.
Les requêtes SQL ne respectent pas les clés uniques et contraintes déclarés dans l'analyse. Avec les requêtes du projet il y a des paramètres pour cela.
3) --- Il me reste toujours une vieille habitude de VB, quand je crée une source de donnée avec un :
*********************************** RS est une source de donnée ***********************************
Doit-on obligatoirement détruire l'objet une fois celui -ci utilisé , en fin de fonction par exemple avec un HAnnuleDéclaration(RS)
on lit partout que oui, car au début de WD7-9, les sources de données étaient globales et ne s'annulaient pas. Depuis WD10, elles s'annulent automatiquement quand le contexte, p.ex. une procédure, dans laquelle elle a été déclaré se ferme. Mais un hAnnuleDeclaration ne fait certes pas de mal.
Salutations Mat
Bonjour,
wd_newbie wrote:
1)---
Quel est le phénomène qui fait pousser des fichiers numérotés dans le
répertoire de l'application ? J'installe mon application, j'ai un
HcreationSiInexistant(*) dans le code de démarrage et au bout de
quelques temps, je trouve des fichiers : clients.001.FIC / factures.
001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
j'ai remarqué ça seulement avec les fichiers de journaux lors d'un
changement de structure, donc une copie de sauvegarde automatique de Windev.
2) --
...
**********************************
Larequete est source de données
SI HexecuterequeteSQL(larequete,"Select * From Clients")
HlitPremier(larequte)
Tantque pas hendehors(larequete)
ListeAjoute( ... etc )
HLitSuivant(laRequete)
FIN
**********************************
Donc si je veux passer mon appli en mode C/S je DOIS utiliser ce type
de code ? Alors que deviennent toutes les fonctions si pratique comme
"EcranVersFichier()" ?
on ne doit pas, mais le résultat de la requête est entièrement en
mémoire vive, donc une boucle est très efficace. On obtient la même
chose avec FichierVersTableMémoire, faut tester pour voir ce qui est
plus efficace. A part cela j'utilise plutôt une boucle POUR TOUT que je
peux également utiliser comme filtre. C'est plus rapide qu'à chaque fois
relancer la requête.
EcranVersFichier devrait probablement lire FicherVersEcran, oui mais
alors il faut avoir lié la source de données au champ.
J'ai un peut de peine a comprendre comment
relier des zones de saisie d'une fenêtre a un resultat de requete qui
n'existe pas encore étant donné que la source de donnée sera
initialisée lors d'un chargement de la fenêtre ou le clic d'un
bouton :
cela marche bien avec une requête du projet. En utilisant le même nom
avec hExecuteRequeteSQL on peut modifier totalement cette requête, on a
donc le meilleur des deux mondes: liaison des champs (pour les états
dans notre cas), flexibilité des requêtes SQL.
On peut également changer les sources de données/liaisons par programmation.
Je ne fais pas de liaison de requêtes avec les champs de saisie pour la
simple raison que la requête ne donne pas de retour si un ajout ou une
modification a vraiment pris place (non plus une suppression. La valeur
retournée confirme que la requête n'a pas d'erreur). Ceci au moins
jusqu'à WD10 que j'utilise, mais je n'ai rien lu que cela aurait changé.
**********************************
ssql est une chaine ="SELECT * FROM Clients"
HexecuteRequeteSQL(larequete,ssql)
**********************************
Ou alors utilisez vous les requêtes "fichier" (créées avec l'éditeur
de requête intégré), mais cela ne risque pas de faire un nombre
impressionnant de requetes.
il y a des gens qui disent que des requêtes utilisant des sources de
données sont plus efficace que les requêtes enregistrées du projet. Je
ne l'ai jamais testé, car dans la plupart des cas, j'utilise des
requêtes comme source de données pour mes états, donc une source de
donnée complique les choses (sauf si les rubriques et champs portent les
mêmes noms, alors on peut créer p.ex. un état avec les champs de fichier
et dans le code d'ouverture de l'état changer la source de données.
Ou est-ce qu'il est MIEUX d'utiliser les fonctions SQL en C/S mais que
les fonctions HF sur les fichiers sont utilisables en C/S mais que les
requêtes SQL sont plus optimisées ?
je n'utilise pas HF C/S, mais avec le couple Windev/HF HP cela ne change
rien: les requêtes sont plus efficace justement pour des requêtes. Pour
les ajouts, modifications et suppressions, j'utilise EcranVersFichier,
hAjoute, hModifie et hSupprime. A mon avis ça donne plus de contrôle et
facilite la vie avec Windev.
Les requêtes SQL ne respectent pas les clés uniques et contraintes
déclarés dans l'analyse. Avec les requêtes du projet il y a des
paramètres pour cela.
3) ---
Il me reste toujours une vieille habitude de VB, quand je crée une
source de donnée avec un :
***********************************
RS est une source de donnée
***********************************
Doit-on obligatoirement détruire l'objet une fois celui -ci utilisé ,
en fin de fonction par exemple avec un HAnnuleDéclaration(RS)
on lit partout que oui, car au début de WD7-9, les sources de données
étaient globales et ne s'annulaient pas. Depuis WD10, elles s'annulent
automatiquement quand le contexte, p.ex. une procédure, dans laquelle
elle a été déclaré se ferme. Mais un hAnnuleDeclaration ne fait certes
pas de mal.
1)--- Quel est le phénomène qui fait pousser des fichiers numérotés dans le répertoire de l'application ? J'installe mon application, j'ai un HcreationSiInexistant(*) dans le code de démarrage et au bout de quelques temps, je trouve des fichiers : clients.001.FIC / factures. 001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
j'ai remarqué ça seulement avec les fichiers de journaux lors d'un changement de structure, donc une copie de sauvegarde automatique de Windev.
2) --
...
********************************** Larequete est source de données
SI HexecuterequeteSQL(larequete,"Select * From Clients")
HlitPremier(larequte) Tantque pas hendehors(larequete)
ListeAjoute( ... etc )
HLitSuivant(laRequete)
FIN **********************************
Donc si je veux passer mon appli en mode C/S je DOIS utiliser ce type de code ? Alors que deviennent toutes les fonctions si pratique comme "EcranVersFichier()" ?
on ne doit pas, mais le résultat de la requête est entièrement en mémoire vive, donc une boucle est très efficace. On obtient la même chose avec FichierVersTableMémoire, faut tester pour voir ce qui est plus efficace. A part cela j'utilise plutôt une boucle POUR TOUT que je peux également utiliser comme filtre. C'est plus rapide qu'à chaque fois relancer la requête.
EcranVersFichier devrait probablement lire FicherVersEcran, oui mais alors il faut avoir lié la source de données au champ.
J'ai un peut de peine a comprendre comment
relier des zones de saisie d'une fenêtre a un resultat de requete qui n'existe pas encore étant donné que la source de donnée sera initialisée lors d'un chargement de la fenêtre ou le clic d'un bouton :
cela marche bien avec une requête du projet. En utilisant le même nom avec hExecuteRequeteSQL on peut modifier totalement cette requête, on a donc le meilleur des deux mondes: liaison des champs (pour les états dans notre cas), flexibilité des requêtes SQL.
On peut également changer les sources de données/liaisons par programmation.
Je ne fais pas de liaison de requêtes avec les champs de saisie pour la simple raison que la requête ne donne pas de retour si un ajout ou une modification a vraiment pris place (non plus une suppression. La valeur retournée confirme que la requête n'a pas d'erreur). Ceci au moins jusqu'à WD10 que j'utilise, mais je n'ai rien lu que cela aurait changé.
********************************** ssql est une chaine ="SELECT * FROM Clients" HexecuteRequeteSQL(larequete,ssql) **********************************
Ou alors utilisez vous les requêtes "fichier" (créées avec l'éditeur de requête intégré), mais cela ne risque pas de faire un nombre impressionnant de requetes.
il y a des gens qui disent que des requêtes utilisant des sources de données sont plus efficace que les requêtes enregistrées du projet. Je ne l'ai jamais testé, car dans la plupart des cas, j'utilise des requêtes comme source de données pour mes états, donc une source de donnée complique les choses (sauf si les rubriques et champs portent les mêmes noms, alors on peut créer p.ex. un état avec les champs de fichier et dans le code d'ouverture de l'état changer la source de données.
Ou est-ce qu'il est MIEUX d'utiliser les fonctions SQL en C/S mais que les fonctions HF sur les fichiers sont utilisables en C/S mais que les requêtes SQL sont plus optimisées ?
je n'utilise pas HF C/S, mais avec le couple Windev/HF HP cela ne change rien: les requêtes sont plus efficace justement pour des requêtes. Pour les ajouts, modifications et suppressions, j'utilise EcranVersFichier, hAjoute, hModifie et hSupprime. A mon avis ça donne plus de contrôle et facilite la vie avec Windev.
Les requêtes SQL ne respectent pas les clés uniques et contraintes déclarés dans l'analyse. Avec les requêtes du projet il y a des paramètres pour cela.
3) --- Il me reste toujours une vieille habitude de VB, quand je crée une source de donnée avec un :
*********************************** RS est une source de donnée ***********************************
Doit-on obligatoirement détruire l'objet une fois celui -ci utilisé , en fin de fonction par exemple avec un HAnnuleDéclaration(RS)
on lit partout que oui, car au début de WD7-9, les sources de données étaient globales et ne s'annulaient pas. Depuis WD10, elles s'annulent automatiquement quand le contexte, p.ex. une procédure, dans laquelle elle a été déclaré se ferme. Mais un hAnnuleDeclaration ne fait certes pas de mal.
Salutations Mat
wd_newbie
On 15 déc, 16:49, mat wrote:
Bonjour,
wd_newbie wrote: > 1)--- > Quel est le phénomène qui fait pousser des fichiers numérotés da ns le > répertoire de l'application ? J'installe mon application, j'ai un > HcreationSiInexistant(*) dans le code de démarrage et au bout de > quelques temps, je trouve des fichiers : clients.001.FIC / factures. > 001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
j'ai remarqué ça seulement avec les fichiers de journaux lors d'un changement de structure, donc une copie de sauvegarde automatique de Winde v. ...
on lit partout que oui, car au début de WD7-9, les sources de données étaient globales et ne s'annulaient pas. Depuis WD10, elles s'annulent automatiquement quand le contexte, p.ex. une procédure, dans laquelle elle a été déclaré se ferme. Mais un hAnnuleDeclaration ne fait ce rtes pas de mal.
Salutations Mat
Merci pour ta réponse, je suis très interréssé par ton explication s ur la réutilisation des requètes:
cela marche bien avec une requête du projet. En utilisant le même nom avec hExecuteRequeteSQL on peut modifier totalement cette requête, on a donc le meilleur des deux mondes: liaison des champs (pour les états dans notre cas), flexibilité des requêtes SQL.
je pense que ça devrait ouvrir pas mal de possibilité
Amicalement
Olivier
On 15 déc, 16:49, mat <NoSPAM-mn...@bluemail.ch> wrote:
Bonjour,
wd_newbie wrote:
> 1)---
> Quel est le phénomène qui fait pousser des fichiers numérotés da ns le
> répertoire de l'application ? J'installe mon application, j'ai un
> HcreationSiInexistant(*) dans le code de démarrage et au bout de
> quelques temps, je trouve des fichiers : clients.001.FIC / factures.
> 001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
j'ai remarqué ça seulement avec les fichiers de journaux lors d'un
changement de structure, donc une copie de sauvegarde automatique de Winde v.
...
on lit partout que oui, car au début de WD7-9, les sources de données
étaient globales et ne s'annulaient pas. Depuis WD10, elles s'annulent
automatiquement quand le contexte, p.ex. une procédure, dans laquelle
elle a été déclaré se ferme. Mais un hAnnuleDeclaration ne fait ce rtes
pas de mal.
Salutations
Mat
Merci pour ta réponse, je suis très interréssé par ton explication s ur
la réutilisation des requètes:
cela marche bien avec une requête du projet. En utilisant le même nom
avec hExecuteRequeteSQL on peut modifier totalement cette requête, on a
donc le meilleur des deux mondes: liaison des champs (pour les états
dans notre cas), flexibilité des requêtes SQL.
je pense que ça devrait ouvrir pas mal de possibilité
wd_newbie wrote: > 1)--- > Quel est le phénomène qui fait pousser des fichiers numérotés da ns le > répertoire de l'application ? J'installe mon application, j'ai un > HcreationSiInexistant(*) dans le code de démarrage et au bout de > quelques temps, je trouve des fichiers : clients.001.FIC / factures. > 001.FIC en plus des fichiers de base Clients.FIC / Membres.FIC ??
j'ai remarqué ça seulement avec les fichiers de journaux lors d'un changement de structure, donc une copie de sauvegarde automatique de Winde v. ...
on lit partout que oui, car au début de WD7-9, les sources de données étaient globales et ne s'annulaient pas. Depuis WD10, elles s'annulent automatiquement quand le contexte, p.ex. une procédure, dans laquelle elle a été déclaré se ferme. Mais un hAnnuleDeclaration ne fait ce rtes pas de mal.
Salutations Mat
Merci pour ta réponse, je suis très interréssé par ton explication s ur la réutilisation des requètes:
cela marche bien avec une requête du projet. En utilisant le même nom avec hExecuteRequeteSQL on peut modifier totalement cette requête, on a donc le meilleur des deux mondes: liaison des champs (pour les états dans notre cas), flexibilité des requêtes SQL.
je pense que ça devrait ouvrir pas mal de possibilité
