[SQLManagerX] Migration projet, gestion des tables temporaires

> Autre point, une grande majorité des fichiers comportent un id
automatique, comment est-ce gérer sur SQLManagerX sachant que ce type
est inexistant sur Firebird ?

Salut,

Faut utiliser les generateurs et faire un trigger pour remplir le champ
lors d'un insert.
Si tu utilise EMS Ibmanager, quand tu crée un champ de type integer, tu
as la possibilite de generer automatiquement les trigger et les
generateur ...

Cordialement,

gg

Jerome PAULIN avait écrit le 01/02/2006 :

Autre point, une grande majorité des fichiers comportent un id automatique,
comment est-ce gérer sur SQLManagerX sachant que ce type est inexistant sur
Firebird ?

Salut,

Faut utiliser les generateurs et faire un trigger pour remplir le champ lors
d'un insert.
Si tu utilise EMS Ibmanager, quand tu crée un champ de type integer, tu as la
possibilite de generer automatiquement les trigger et les generateur ...

Cordialement,

gg

Est-ce qu'il y a un moyen pour reprendre une analyse HF et en générer
le script SQL de création des tables, index, etc ...

"VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de
news:mn.0c2b7d62a8db1ec3.48802@free.Fr...

J'ai un projet WD9 HF (donc basé sur une analyse)

Si je veux migrer sur firebird. puis-je continuer à le système
hyperfile classic pour des fichiers temporaires.

Oui aucun problème. Vu qu'un projet SQLManagerX ne nécessite pas d'analyse,
il n'y aura pas d'effets de bord.

Si oui, doivent t'il être décrit dans l'analyse (des états doivent se
baser dessus)

Quant à décrire les fichiers dans l'analyse ou non, c'est plus à toi de voir
en fonction de tes besoins.

Question subsiliaire : Je pense que je rêve un peu,mais est-ce que
faire un rechercher/remplacer pour les ordres H... suffit à basculer
vers SQLManagerX dans le code ?

Presque :) un hlitpremier(clients) devient I_Clients:SQLPremier().

En gros, est-ce que les paramètres des
fonctions de SQLManagerX sont à l'identique des fonctions Hxxxxxx

Nous reprenons le principe mais pas l'iso-comportement. Ceci pour éviter
l'amalgame qu'un développeur pourrait faire entre le comportement avec les
ordres Hxxx et les méthodes SQLManagerX qui peuvent différer dans le temps.
A ce sujet, si tu t'orientes sur un SGBD standard, il faut aussi prévoir une
phase de migration en SQL (bien plus simple et optimisé) de certains
traitements.

Autre point, une grande majorité des fichiers comportent un id
automatique, comment est-ce gérer sur SQLManagerX sachant que ce type
est inexistant sur Firebird ?

A chaque insert SQLManagerX récupère en base le dernier id crée (MySQL,
SQLite, PostGre). Sous FireBird (comme pour Oracle) cette récupération n'est
pas effectuée car je ne l'ai pas encore mise dans la classe (comme tu le dis
ce n'est pas un type standard pour ces bases et pas de demande à ce sujet
jusqu'à maintenant). La solution Firebird consiste à créer un GENERATOR. Il
est très simple de prendre une norme de création de générateur du type :
GEN_NomTable_NomColonne, un simple select GEN_ID(GEN_MYTABLE_ID,1) nous
donnera la valeur à insérer.

En espérant avoir répondu correctement à tes interrogations. Si tu as
d'autres questions :)

Voilà.

"VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de
news:mn.0c727d62c65fa095.48802@free.Fr...

Jerome PAULIN avait écrit le 01/02/2006 :
>> Autre point, une grande majorité des fichiers comportent un id

automatique,

>> comment est-ce gérer sur SQLManagerX sachant que ce type est inexistant

sur

>> Firebird ?
>>
>
> Salut,
>
> Faut utiliser les generateurs et faire un trigger pour remplir le champ

lors

> d'un insert.
> Si tu utilise EMS Ibmanager, quand tu crée un champ de type integer, tu

as la

> possibilite de generer automatiquement les trigger et les generateur ...
>
> Cordialement,
>
> gg

Est-ce qu'il y a un moyen pour reprendre une analyse HF et en générer
le script SQL de création des tables, index, etc ...

Oui SQLManagerXConverter :) dispo ici :
http://www.sqlmanagerx.com/websqlx/html/modules/mydownloads/visit.php?cid=3&lid=7

Désolé par contre, pour le moment il ne génère pas les GENERATOR.

Bonjour,

"VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de news:
mn.0c2b7d62a8db1ec3.48802@free.Fr...

J'ai un projet WD9 HF (donc basé sur une analyse)

Si je veux migrer sur firebird. puis-je continuer à le système hyperfile
classic pour des fichiers temporaires.
Si oui, doivent t'il être décrit dans l'analyse (des états doivent se
baser dessus)

aucun probleme SQLManagerX n'a pas besoin de l'analyse mais il peut en
exister une. sur un gros projet a migrer j'ai meme eu temporairement les
deux
le temp de tout migrer il aurait fallu attendre, donc on a remplacer petit a
petit
les fichier HF et meme des table de la base SQL (car la persone utilisait
aussi un acces
natif de l'editeur) petit a petit on a remplacer tout par des objet
SQLManagerX.
il est rester certain fichier en HF donc l'analyse finale ne contenait plus
que ces fichiers

Question subsiliaire : Je pense que je rêve un peu,mais est-ce que faire
un rechercher/remplacer pour les ordres H... suffit à basculer vers
SQLManagerX dans le code ? En gros, est-ce que les paramètres des
fonctions de SQLManagerX sont à l'identique des fonctions Hxxxxxx

meme si les fonctions SQLManagerX essayent de se raprocher des ordre H
elles ne sont pas identiques leur fonctionnement l'est mais pas les appel et
manu a
monter comment elles etaient differentes. j'ajouterais au discour de manu
que
l'algorithmique est la meme :

une boucle
hfiltre(monfichier,"macondition)
hlitpremier(monficher,macle)
tantque pas h.endhors
info(monFic.nom)
hlitdsuivant(monfichier,macle)
fin

se traduit exactement pareil en SQLManagerX
matable:SQLfiltre(condition,order)
matable:SQLPremier()
tantque pas matable:endehors
info(matable:nom)
matable:SQLSuivant
fin

vous avez une idee de la difference de code. mais l'algorithmique
peut etre completement identique.

Autre point, une grande majorité des fichiers comportent un id
automatique, comment est-ce gérer sur SQLManagerX sachant que ce type est
inexistant sur Firebird ?

quant le type auto §Incrment n'existe pas je m'arrange pour le recreer soit
par une
table parametre qui me donne l'identifiant, soit directement en
programmation avec un +1
sur le dernier id.
SQLManagerX peut simplement avec son converter vous les transferer, c'est a
dire
qu'il conservera les liaisons des autoincrement et les valeur existante.
ensuite a vous
de faire continuer cette sequence

Vincent.

Firetox

Emmanuel Lecoester a exposé le 01/02/2006 :

"VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de
news:mn.0c2b7d62a8db1ec3.48802@free.Fr...

J'ai un projet WD9 HF (donc basé sur une analyse)

Si je veux migrer sur firebird. puis-je continuer à le système
hyperfile classic pour des fichiers temporaires.

Oui aucun problème. Vu qu'un projet SQLManagerX ne nécessite pas d'analyse,
il n'y aura pas d'effets de bord.

Si oui, doivent t'il être décrit dans l'analyse (des états doivent se
baser dessus)

Quant à décrire les fichiers dans l'analyse ou non, c'est plus à toi de voir
en fonction de tes besoins.

Question subsiliaire : Je pense que je rêve un peu,mais est-ce que
faire un rechercher/remplacer pour les ordres H... suffit à basculer
vers SQLManagerX dans le code ?

Presque :) un hlitpremier(clients) devient I_Clients:SQLPremier().

En gros, est-ce que les paramètres des
fonctions de SQLManagerX sont à l'identique des fonctions Hxxxxxx

Nous reprenons le principe mais pas l'iso-comportement. Ceci pour éviter
l'amalgame qu'un développeur pourrait faire entre le comportement avec les
ordres Hxxx et les méthodes SQLManagerX qui peuvent différer dans le temps.
A ce sujet, si tu t'orientes sur un SGBD standard, il faut aussi prévoir une
phase de migration en SQL (bien plus simple et optimisé) de certains
traitements.

Autre point, une grande majorité des fichiers comportent un id
automatique, comment est-ce gérer sur SQLManagerX sachant que ce type
est inexistant sur Firebird ?

A chaque insert SQLManagerX récupère en base le dernier id crée (MySQL,
SQLite, PostGre). Sous FireBird (comme pour Oracle) cette récupération n'est
pas effectuée car je ne l'ai pas encore mise dans la classe (comme tu le dis
ce n'est pas un type standard pour ces bases et pas de demande à ce sujet
jusqu'à maintenant). La solution Firebird consiste à créer un GENERATOR. Il
est très simple de prendre une norme de création de générateur du type :
GEN_NomTable_NomColonne, un simple select GEN_ID(GEN_MYTABLE_ID,1) nous
donnera la valeur à insérer.

Une évolution sympathique de la classe serait la notion d'identifiant
unique automatique (a ne pas confondre avec un champ en numéro auto).

Je pense plus à la notion de GUID (il me semble que c'est le nom) de
SQL Serveur ou de DocumentID de Domino.
Même si les id auto facilite la vie, il pose un gros problème quand on
veut faire de la réplication de base ou merger pusieurs bases
simplement.

Avantage, que 2 sites travaille sur une réplique de la base et
synchroniser les répliques périodiquement.

ou pouvoir travailler en mode autonome sur une version réduite de la
base et réintégrer ces modifications après coup.

Or les identifiants en numéro auto complique plus grandement la tache
dans ces cas là.

En espérant avoir répondu correctement à tes interrogations. Si tu as
d'autres questions :)

Merci à toi de consacrer du temps à ce forum

Voilà.

"VincentC" <VNO.SPAM_perso@free.Fr> writes:

Emmanuel Lecoester a exposé le 01/02/2006 :
> "VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de
>news:mn.0c2b7d62a8db1ec3.48802@free.Fr...
>> J'ai un projet WD9 HF (donc basé sur une analyse) Si je veux migrer
>>sur firebird. puis-je continuer à le système hyperfile classic pour
>>des fichiers temporaires.
> Oui aucun problème. Vu qu'un projet SQLManagerX ne nécessite pas
>d'analyse, il n'y aura pas d'effets de bord.
>
>> Si oui, doivent t'il être décrit dans l'analyse (des états doive nt
>>se baser dessus)
> Quant à décrire les fichiers dans l'analyse ou non, c'est plus à toi
>de voir en fonction de tes besoins.
>
>> Question subsiliaire : Je pense que je rêve un peu,mais est-ce que
>>faire un rechercher/remplacer pour les ordres H... suffit à basculer
>>vers SQLManagerX dans le code ?
> Presque :) un hlitpremier(clients) devient I_Clients:SQLPremier().
>
>> En gros, est-ce que les paramètres des fonctions de SQLManagerX
>>sont à l'identique des fonctions Hxxxxxx
> Nous reprenons le principe mais pas l'iso-comportement. Ceci pour
>éviter l'amalgame qu'un développeur pourrait faire entre le
>comportement avec les ordres Hxxx et les méthodes SQLManagerX qui
>peuvent différer dans le temps. A ce sujet, si tu t'orientes sur un
>SGBD standard, il faut aussi prévoir une phase de migration en SQL
>(bien plus simple et optimisé) de certains traitements.
>
>> Autre point, une grande majorité des fichiers comportent un id
>>automatique, comment est-ce gérer sur SQLManagerX sachant que ce
>>type est inexistant sur Firebird ?
> A chaque insert SQLManagerX récupère en base le dernier id crée
>(MySQL, SQLite, PostGre). Sous FireBird (comme pour Oracle) cette
>récupération n'est pas effectuée car je ne l'ai pas encore mise da ns
>la classe (comme tu le dis ce n'est pas un type standard pour ces
>bases et pas de demande à ce sujet jusqu'à maintenant). La solution
>Firebird consiste à créer un GENERATOR. Il est très simple de pren dre
>une norme de création de générateur du type :
>GEN_NomTable_NomColonne, un simple select GEN_ID(GEN_MYTABLE_ID,1)
>nous donnera la valeur à insérer.

Une évolution sympathique de la classe serait la notion d'identifiant
unique automatique (a ne pas confondre avec un champ en numéro auto).

Je pense plus à la notion de GUID (il me semble que c'est le nom) de
SQL Serveur ou de DocumentID de Domino. Même si les id auto facilite
la vie, il pose un gros problème quand on veut faire de la réplication
de base ou merger pusieurs bases simplement.

sauf que le GUID est unique sur le poste où tu travailles, mais pas
sur l'ensemble des postes, il faut donc que celà soit géré par le
moteur de la base, ce qui doit être le cas de SQLserver?

Donc on revient sur le principe d'un trigger.


Autre inconvénient, pour lequel on ne doit pas le gérer par la classe
c'est que tout le monde ne travaille pas en environnment homogène, et
il n'est pas rare que certes la partie cliente soit sous Windev, mais
que des bouts de codes en C ou autre fonctionne directement sur les
serveurs qui eux sont peut être sous Unix.

Il faut faire attention que SQMX ne fasse pas "tout", car on va
retomber dans du spécifique et il va devenir très difficile de tout
maintenir.

Je prend un exemple tout bête qui est la gestion des "timestamp". Sous
Mysql, si la valeur retournée est null le serveur, va lui même mettre
la valeur du timestamp, sous Postgresql ce n'est pas le cas.

Dans le cas de mysql, c'est donc "automatique" et on n' a pas à le
gérer sous SQMX, sous Postgresql 2 solutions possibles:
- on le gère sous SQMX, c'est pas difficile à faire si on est dans le
cas d'une table, mais si on travaille avec des tables liées c'est du
cas par cas donc ingérable.
- ou on met un trigger sur la ou les tables. C'est la solution la plus
simple et la plus efficace.


Aujourd'hui, avec SQMX nous avons la chance que quasiment toutes les
bases gèrent les triggers (MySQL V5 le fait), il faut à mon avis
profiter de cette opportunité pour accroitre la possibilité d'un code
unique pour des bases différentes.

Avantage, que 2 sites travaille sur une réplique de la base et
synchroniser les répliques périodiquement.

ou pouvoir travailler en mode autonome sur une version réduite de la
base et réintégrer ces modifications après coup.

Or les identifiants en numéro auto complique plus grandement la tache
dans ces cas là.

> En espérant avoir répondu correctement à tes interrogations. Si tu
>as d'autres questions :)
>

Merci à toi de consacrer du temps à ce forum

> Voilà.

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)

Daniel a exposé le 02/02/2006 :

sauf que le GUID est unique sur le poste où tu travailles, mais pas
sur l'ensemble des postes, il faut donc que celà soit géré par le
moteur de la base, ce qui doit être le cas de SQLserver?

Non, non, un GUID (G pour GLOBAL) est unique (enfin, dans la limite des
probabilités)
http://fr.wikipedia.org/wiki/GUID
http://fr.wikipedia.org/wiki/UUID

http://groups.google.fr/group/fr.comp.developpement.agl.windev/msg/cb876b59bf5307bd?hl=fr&

A+

--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)

Le 02/02/2006, Daniel a supposé :

sauf que le GUID est unique sur le poste où tu travailles, mais pas
sur l'ensemble des postes, il faut donc que celà soit géré par le
moteur de la base, ce qui doit être le cas de SQLserver?

Donc on revient sur le principe d'un trigger.


Autre inconvénient, pour lequel on ne doit pas le gérer par la classe
c'est que tout le monde ne travaille pas en environnment homogène, et
il n'est pas rare que certes la partie cliente soit sous Windev, mais
que des bouts de codes en C ou autre fonctionne directement sur les
serveurs qui eux sont peut être sous Unix.

Il faut faire attention que SQMX ne fasse pas "tout", car on va
retomber dans du spécifique et il va devenir très difficile de tout
maintenir.

Je prend un exemple tout bête qui est la gestion des "timestamp". Sous
Mysql, si la valeur retournée est null le serveur, va lui même mettre
la valeur du timestamp, sous Postgresql ce n'est pas le cas.

Dans le cas de mysql, c'est donc "automatique" et on n' a pas à le
gérer sous SQMX, sous Postgresql 2 solutions possibles:
- on le gère sous SQMX, c'est pas difficile à faire si on est dans le
cas d'une table, mais si on travaille avec des tables liées c'est du
cas par cas donc ingérable.
- ou on met un trigger sur la ou les tables. C'est la solution la plus
simple et la plus efficace.


Aujourd'hui, avec SQMX nous avons la chance que quasiment toutes les
bases gèrent les triggers (MySQL V5 le fait), il faut à mon avis
profiter de cette opportunité pour accroitre la possibilité d'un code
unique pour des bases différentes.

Je suis conscient que ce type d'amélioration alourdi la maintenance. Je
trouvé que l'implantation d'un type GUID (vraiment global comme le
souligné romain) dans SQLmangerX apporté un avantage supplémentaire à
la migration de projet.

Je pense aussi que création du GUID peux être effectué par un trigger,
ce qui simplifie le cas des tables liés. Maintenant rien n'empêche une
automatisation de la création du trigger quand on fait la migration HF
-> Firebird.

Bien sur, ce n'est qu'une suggestion d'évolution en aucun cas un
reproche sur SQLManagerX.

>Bien sur, ce n'est qu'une suggestion d'évolution en aucun cas un
reproche sur SQLManagerX.

lol. N'aie pas peur personnellement je ne l'ai pas pris pour une
critique. La réponse de Daniel est simplement le type de réponse que
l'on se fait entre nous pour discuter de telle ou telle amélioration.
Chacun donne son point de vue (avantages / inconvénients) et on prend
la solution la plus pérenne.

Tout çà pour te dire que nous allons nous pencher sur ce point :-)

--
Emmanuel