Votre avis pour des états en client/Serveur (hors HF) ?

Le
Côme de Christen
Bonjour

Je sollicite votre avis sur le point suivant.
Je veux développer en client/serveur avec mettons MySql (donc pas de HF).

A ce stade tout est ok et réglé pour les fenêtres, je n'utilise que du SQLExec,
simple et direct.
(même si j'ai une analyse non synchronisée pour faciliter la création initiale
des fenêtres et documenter le schéma de la base).

J'en arrive au point qui me pose encore dilemme : les états. A ce stade, pour
rester dans ma logique d'un accès le plus bref et le plus transparent possible
(sans interférence windev) avec la base, j'envisage des états avec source
programmée avec en gros le fonctionnement suivant :

- une fenêtre classique permet au user de spécifier ses critères d'édtions
- la validation construit la chaine sql correspondante et la transmet à l'état
en paramètre
- l'état ouvre la connexion BD et appelle SQLExec pour la requête SQL. Il
injecte alors les lignes dans un tableau de structure adapté déclaré dans l'état
- l'état coupe la connexion BD
- L'état parcourt le tableau pour constituer le corps de l'état.

Techniquement ça va forcément marcher et normalement rapidement avec le moins
d'interférence possible avec la base.
Bon je perds évidemment certaines fonctionnalités de l'AGL mais je l'espère au
profit d'une plus grande stabilité / performance

Mes questions sont :

- Est-ce ce que vous faites ?
- Quel(s) désavantage(s) voyez-vous, le cas échéant, dans cette façon de
faire ?

Côme
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
JeAn-PhI
Le #23104251
Côme de Christen avait prétendu :
Bonjour

Je sollicite votre avis sur le point suivant.
Je veux développer en client/serveur avec mettons MySql (donc pas de HF).

A ce stade tout est ok et réglé pour les fenêtres, je n'utilise que du
SQLExec, simple et direct.
(même si j'ai une analyse non synchronisée pour faciliter la création
initiale des fenêtres et documenter le schéma de la base).

J'en arrive au point qui me pose encore dilemme : les états. A ce stade, pour
rester dans ma logique d'un accès le plus bref et le plus transparent
possible (sans interférence windev) avec la base, j'envisage des états avec
source programmée avec en gros le fonctionnement suivant :

- une fenêtre classique permet au user de spécifier ses critères d'édtions
- la validation construit la chaine sql correspondante et la transmet à
l'état en paramètre
- l'état ouvre la connexion BD et appelle SQLExec pour la requête SQL. Il
injecte alors les lignes dans un tableau de structure adapté déclaré dans
l'état
- l'état coupe la connexion BD
- L'état parcourt le tableau pour constituer le corps de l'état.

Techniquement ça va forcément marcher et normalement rapidement avec le moins
d'interférence possible avec la base.
Bon je perds évidemment certaines fonctionnalités de l'AGL mais je l'espère
au profit d'une plus grande stabilité / performance

Mes questions sont :

- Est-ce ce que vous faites ?


presque, je parcours la requête dans l'état
- Quel(s) désavantage(s) voyez-vous, le cas échéant, dans cette façon de
faire ?


aucun dans la mesure où j'utilise l'accès alternatif SQLManagerX pour
accéder à MySQL et que on ne peut pas dans ce cas faire autrement si ce
n'est de faire un état sur table. dans ce cas c'est plus rapide car les
données sont déjà monter dans le champ table

Côme



--
Cordialement JeAn-PhI
Firetox
Le #23104491
Bonjour,

aucun dans la mesure où j'utilise l'accès alternatif SQLManagerX pour
accéder à MySQL et que on ne peut pas dans ce cas faire autrement si ce
n'est de faire un état sur table. dans ce cas c'est plus rapide car les
données sont déjà monter dans le champ table

Cordialement JeAn-PhI



il y a meme un generateur d'etat dans SQLManagerX avec les etat de la classe
une requete suffit pour avoir un etat en plus en nommant les colonne d'une
certaine façon on peut intervenir sur le format et faire des ruptures :

voir ici : SQLEdit (methode SQLManagerX)
http://www.sqlmanagerx.com/websqlx/html/modules/news/article.php?storyid@

cordialement
Jacques Trepp
Le #23104481
JeAn-PhI avait écrit le 09/02/2011 :
Côme de Christen avait prétendu :
Bonjour

Je sollicite votre avis sur le point suivant.
Je veux développer en client/serveur avec mettons MySql (donc pas de HF).

A ce stade tout est ok et réglé pour les fenêtres, je n'utilise que du
SQLExec, simple et direct.
(même si j'ai une analyse non synchronisée pour faciliter la création
initiale des fenêtres et documenter le schéma de la base).

J'en arrive au point qui me pose encore dilemme : les états. A ce stade,
pour rester dans ma logique d'un accès le plus bref et le plus transparent
possible (sans interférence windev) avec la base, j'envisage des états avec
source programmée avec en gros le fonctionnement suivant :

- une fenêtre classique permet au user de spécifier ses critères d'édtions
- la validation construit la chaine sql correspondante et la transmet à
l'état en paramètre
- l'état ouvre la connexion BD et appelle SQLExec pour la requête SQL. Il
injecte alors les lignes dans un tableau de structure adapté déclaré dans
l'état
- l'état coupe la connexion BD
- L'état parcourt le tableau pour constituer le corps de l'état.

Techniquement ça va forcément marcher et normalement rapidement avec le
moins d'interférence possible avec la base.
Bon je perds évidemment certaines fonctionnalités de l'AGL mais je l'espère
au profit d'une plus grande stabilité / performance

Mes questions sont :

- Est-ce ce que vous faites ?


presque, je parcours la requête dans l'état
- Quel(s) désavantage(s) voyez-vous, le cas échéant, dans cette façon
de faire ?


aucun dans la mesure où j'utilise l'accès alternatif SQLManagerX pour accéder
à MySQL et que on ne peut pas dans ce cas faire autrement si ce n'est de
faire un état sur table. dans ce cas c'est plus rapide car les données sont
déjà monter dans le champ table

Côme





Pareil pour moi: windev et mysql ou postgresql et acces SQLManagerX.
ça passe forcément par une table, mais les clients apprécient de
visualiser les résultats sans faire d'aperçu. Après un état sur table
fait très bien l'affaire.
jacques
JeAn-PhI
Le #23105551
Firetox vient de nous annoncer :
Bonjour,

aucun dans la mesure où j'utilise l'accès alternatif SQLManagerX pour
accéder à MySQL et que on ne peut pas dans ce cas faire autrement si ce
n'est de faire un état sur table. dans ce cas c'est plus rapide car les
données sont déjà monter dans le champ table



Cordialement JeAn-PhI



il y a meme un generateur d'etat dans SQLManagerX avec les etat de la classe
une requete suffit pour avoir un etat en plus en nommant les colonne d'une
certaine façon on peut intervenir sur le format et faire des ruptures :



c'est vrai j'avais oublier, comme j'ai toujours programmé mes états
même en HF
voir ici : SQLEdit (methode SQLManagerX)
http://www.sqlmanagerx.com/websqlx/html/modules/news/article.php?storyid@

cordialement



--
Cordialement JeAn-PhI
Côme
Le #23107571
Bonsoir,

Merci pour vos réponses, je vais regarder SQLManagerX. Le site mentionnait un
fonctionnement de la version 7.5 jusqu'à la version 12 et j'ai du coup supposé
que le projet n'était plus trop maintenu.

L'accès annoncé pour Firebird me plait bien !

Côme
Goof
Le #23189381
Salut

Pas exactement car nous sommes en HF ou HF classique.

Mais ca nous sert a construire des états non linéaires avec ligne
principale et des détails/sous détails .....

Beaucoup plus simple que de programmer l'état avec le parcours de la
requête et les exécutions de sous requêtes pour chaque ligne de détail.

On construit une structure contenant des tableau de structures imbriqués
Avant l'impression de l'état, puis, dans l'état on parcours
l'enchevêtrement de structures pour afficher les lignes correctes dans
le parcours de l'état et éventuellement les blocs d'itérations
nécessaires aux sous-détails dans les traitements du corps ou les blocs
d'itérations précédents.

A++
Goof

Le 09/02/2011 01:57, Côme de Christen a écrit :

Mes questions sont :

- Est-ce ce que vous faites ?
- Quel(s) désavantage(s) voyez-vous, le cas échéant, dans cette façon de
faire ?

Côme


Publicité
Poster une réponse
Anonyme