Votre avis pour des états en client/Serveur (hors HF) ?
6 réponses
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 ?
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
JeAn-PhI
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
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
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
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 :
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 :
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 :
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 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
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
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
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
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
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
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.
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
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
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 ?
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 ?
