Utilisation C/S et autre ...

Le
wd_newbie
Bonjour,

je me remets a vous pour quelques petites questions concernant Windev
Je viens de terminer une petite application d'une cinquantaine de
fenêtres + des états.
Celle-ci est basée exclusivement sur HF en mode local. Elle représente
pas mal de temps de développement, mais je l'ai créée pour "pour
apprendre" Windev.

Au terme de cette applications, il me reste des questions dont je ne
trouve pas vraiment la réponse, et je m'en remets donc a votre
expérience.

1)
Quel est le phénomène qui fait pousser des fichiers numérotés dans l=
e
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 ??

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égier les requêtes SQL pour améliorer 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é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()" ? 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 :

**********************************
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.

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 ?

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)



J'espère que j'ai été assez clair dans mes explications


Amicalement

Olivier
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mat
Le #14564371
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
wd_newbie
Le #14564101
On 15 déc, 16:49, mat
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
Publicité
Poster une réponse
Anonyme