[SQLManagerX] Migration projet, gestion des tables temporaires
14 réponses
VincentC
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)
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
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 ?
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.
J'avais juste apporté cette précision, pour éviter que quelques parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinement justifié ainsi que celles des autres participants.
Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
Bon dev.
Dans son message précédent, elecoest@netcourrier.com a écrit :
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.
J'avais juste apporté cette précision, pour éviter que quelques
parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinement
justifié ainsi que celles des autres participants.
Tout çà pour te dire que nous allons nous pencher sur ce point :-)
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.
J'avais juste apporté cette précision, pour éviter que quelques parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinement justifié ainsi que celles des autres participants.
Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
Bon dev.
Daniel
Bonsoir,
"VincentC" writes:
Dans son message précédent, a écrit : >> 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. J'avais juste apporté cette précision, pour éviter que quelques parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinem ent justifié ainsi que celles des autres participants. > > Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
En fait j'ai reformulé la question pour bien comprendre la demande.
Concernant la remarque de Romain, j'ai une phrase qui me gène dans la définition du numéro unique dans le "temps et dans l'espace". Sinon merci pour le lien.
Concernant l'idée du GUID pour l'identifiant unique sur la base, l'idée me plait bien, maintenant la question reste entière faut il l'implémenter dans la couche client (je pense à SQMX) ou dans la couche serveur avec un trigger?
Concernant la remarque d'ordre général, pas de soucis on s'entend tous très bien, et on sait que toutes remarques aussi minime soit elle peut nous aider à faire évoluer le projet (sinon on aurait arrêté car le SM ce n'est pas pour nous ;-)).
Bon dev.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bonsoir,
"VincentC" <VNO.SPAM_perso@free.Fr> writes:
Dans son message précédent, elecoest@netcourrier.com a écrit :
>> 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.
J'avais juste apporté cette précision, pour éviter que quelques
parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinem ent
justifié ainsi que celles des autres participants.
>
> Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
En fait j'ai reformulé la question pour bien comprendre la demande.
Concernant la remarque de Romain, j'ai une phrase qui me gène dans la
définition du numéro unique dans le "temps et dans l'espace". Sinon
merci pour le lien.
Concernant l'idée du GUID pour l'identifiant unique sur la base,
l'idée me plait bien, maintenant la question reste entière faut il
l'implémenter dans la couche client (je pense à SQMX) ou dans la
couche serveur avec un trigger?
Concernant la remarque d'ordre général, pas de soucis on s'entend tous
très bien, et on sait que toutes remarques aussi minime soit elle peut
nous aider à faire évoluer le projet (sinon on aurait arrêté car le SM
ce n'est pas pour nous ;-)).
Bon dev.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Dans son message précédent, a écrit : >> 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. J'avais juste apporté cette précision, pour éviter que quelques parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinem ent justifié ainsi que celles des autres participants. > > Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
En fait j'ai reformulé la question pour bien comprendre la demande.
Concernant la remarque de Romain, j'ai une phrase qui me gène dans la définition du numéro unique dans le "temps et dans l'espace". Sinon merci pour le lien.
Concernant l'idée du GUID pour l'identifiant unique sur la base, l'idée me plait bien, maintenant la question reste entière faut il l'implémenter dans la couche client (je pense à SQMX) ou dans la couche serveur avec un trigger?
Concernant la remarque d'ordre général, pas de soucis on s'entend tous très bien, et on sait que toutes remarques aussi minime soit elle peut nous aider à faire évoluer le projet (sinon on aurait arrêté car le SM ce n'est pas pour nous ;-)).
Bon dev.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
VincentC
Daniel a présenté l'énoncé suivant :
Bonsoir,
"VincentC" writes:
Dans son message précédent, a écrit :
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.
J'avais juste apporté cette précision, pour éviter que quelques parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinement justifié ainsi que celles des autres participants.
Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
En fait j'ai reformulé la question pour bien comprendre la demande.
Concernant la remarque de Romain, j'ai une phrase qui me gène dans la définition du numéro unique dans le "temps et dans l'espace". Sinon merci pour le lien.
Concernant l'idée du GUID pour l'identifiant unique sur la base, l'idée me plait bien, maintenant la question reste entière faut il l'implémenter dans la couche client (je pense à SQMX) ou dans la couche serveur avec un trigger?
A mon avis, ce doit être sur la couche serveur. 1- comment dis précedemment, l'accès à la base n'est pas restreint à une application windev. Donc Plusieurs appli (windev ou non) et utilisant ou non SQLManagerX peut être amené à écrire dans la base (pas forcément dans les même tables, mais on ne sait jamais). 2- Si un Trigger dans la base de donnée doit créér des enregistrements dans une table ayant cette id automatique, il faut lui apprendre à construire un id automatique ...
Pour moi, étant donné que l'id caractérise l'enregistrement de la base de données ** indépendamment ** des applications qui l'utilise, c'est au serveur d'implémenter le mécanisme quand il le peut.
Comment faire quand une base de donnée ne contient pas de type GUID natif ou ne gére pas les trigger ?
Concernant la remarque d'ordre général, pas de soucis on s'entend tous très bien, et on sait que toutes remarques aussi minime soit elle peut nous aider à faire évoluer le projet (sinon on aurait arrêté car le SM ce n'est pas pour nous ;-)).
Bon dev.
Daniel a présenté l'énoncé suivant :
Bonsoir,
"VincentC" <VNO.SPAM_perso@free.Fr> writes:
Dans son message précédent, elecoest@netcourrier.com a écrit :
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.
J'avais juste apporté cette précision, pour éviter que quelques
parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinement
justifié ainsi que celles des autres participants.
Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
En fait j'ai reformulé la question pour bien comprendre la demande.
Concernant la remarque de Romain, j'ai une phrase qui me gène dans la
définition du numéro unique dans le "temps et dans l'espace". Sinon
merci pour le lien.
Concernant l'idée du GUID pour l'identifiant unique sur la base,
l'idée me plait bien, maintenant la question reste entière faut il
l'implémenter dans la couche client (je pense à SQMX) ou dans la
couche serveur avec un trigger?
A mon avis, ce doit être sur la couche serveur.
1- comment dis précedemment, l'accès à la base n'est pas restreint à
une application windev. Donc Plusieurs appli (windev ou non) et
utilisant ou non SQLManagerX peut être amené à écrire dans la base (pas
forcément dans les même tables, mais on ne sait jamais).
2- Si un Trigger dans la base de donnée doit créér des enregistrements
dans une table ayant cette id automatique, il faut lui apprendre à
construire un id automatique ...
Pour moi, étant donné que l'id caractérise l'enregistrement de la base
de données ** indépendamment ** des applications qui l'utilise, c'est
au serveur d'implémenter le mécanisme quand il le peut.
Comment faire quand une base de donnée ne contient pas de type GUID
natif ou ne gére pas les trigger ?
Concernant la remarque d'ordre général, pas de soucis on s'entend tous
très bien, et on sait que toutes remarques aussi minime soit elle peut
nous aider à faire évoluer le projet (sinon on aurait arrêté car le SM
ce n'est pas pour nous ;-)).
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.
J'avais juste apporté cette précision, pour éviter que quelques parasites bien connu, ne s'accroche au thread.
Ca ne concerné en aucun cas, la réponse de Daniel qui était pleinement justifié ainsi que celles des autres participants.
Tout çà pour te dire que nous allons nous pencher sur ce point :-)
Alors j'attend la décision avec impatience :-)
En fait j'ai reformulé la question pour bien comprendre la demande.
Concernant la remarque de Romain, j'ai une phrase qui me gène dans la définition du numéro unique dans le "temps et dans l'espace". Sinon merci pour le lien.
Concernant l'idée du GUID pour l'identifiant unique sur la base, l'idée me plait bien, maintenant la question reste entière faut il l'implémenter dans la couche client (je pense à SQMX) ou dans la couche serveur avec un trigger?
A mon avis, ce doit être sur la couche serveur. 1- comment dis précedemment, l'accès à la base n'est pas restreint à une application windev. Donc Plusieurs appli (windev ou non) et utilisant ou non SQLManagerX peut être amené à écrire dans la base (pas forcément dans les même tables, mais on ne sait jamais). 2- Si un Trigger dans la base de donnée doit créér des enregistrements dans une table ayant cette id automatique, il faut lui apprendre à construire un id automatique ...
Pour moi, étant donné que l'id caractérise l'enregistrement de la base de données ** indépendamment ** des applications qui l'utilise, c'est au serveur d'implémenter le mécanisme quand il le peut.
Comment faire quand une base de donnée ne contient pas de type GUID natif ou ne gére pas les trigger ?
Concernant la remarque d'ordre général, pas de soucis on s'entend tous très bien, et on sait que toutes remarques aussi minime soit elle peut nous aider à faire évoluer le projet (sinon on aurait arrêté car le SM ce n'est pas pour nous ;-)).
Bon dev.
Daniel
"VincentC" writes:
Daniel a présenté l'énoncé suivant : > > Bonsoir, > > "VincentC" writes: > >> Dans son message précédent, a écrit : >>>> 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élioratio n. >>> Chacun donne son point de vue (avantages / inconvénients) et on pre nd >>> la solution la plus pérenne. >> J'avais juste apporté cette précision, pour éviter que quelques >> parasites bien connu, ne s'accroche au thread. >> Ca ne concerné en aucun cas, la réponse de Daniel qui était >> pleinement >> justifié ainsi que celles des autres participants. >>> Tout çà pour te dire que nous allons nous pencher sur ce point :-) >> Alors j'attend la décision avec impatience :-) > > En fait j'ai reformulé la question pour bien comprendre la demande. > > Concernant la remarque de Romain, j'ai une phrase qui me gène dans la > définition du numéro unique dans le "temps et dans l'espace". Sinon > merci pour le lien. > > Concernant l'idée du GUID pour l'identifiant unique sur la base, > l'idée me plait bien, maintenant la question reste entière faut il > l'implémenter dans la couche client (je pense à SQMX) ou dans la > couche serveur avec un trigger? >
A mon avis, ce doit être sur la couche serveur. 1- comment dis précedemment, l'accès à la base n'est pas restreint à une application windev. Donc Plusieurs appli (windev ou non) et utilisant ou non SQLManagerX peut être amené à écrire dans la base (pas forcément dans les même tables, mais on ne sait jamais). 2- Si un Trigger dans la base de donnée doit créér des enregistreme nts dans une table ayant cette id automatique, il faut lui apprendre à construire un id automatique ...
Pour moi, étant donné que l'id caractérise l'enregistrement de la b ase de données ** indépendamment ** des applications qui l'utilise, c'est au serveur d'implémenter le mécanisme quand il le peut.
Comment faire quand une base de donnée ne contient pas de type GUID
A la limite peut être le gérer soi même cf http://www.ietf.org/rfc/rfc4122.txt qui est très intéressant
natif ou ne gére pas les trigger ?
si pas de trigger on change de base ;-), ou voir si implémentable en fonction possible. Aujourd'hui même MySQL gère les triggers. On a tout de même le choix entre Firebird, Postgresql, SQLserver, Sybase, Oracle, Mysql, HF...
> Concernant la remarque d'ordre général, pas de soucis on s'entend t ous > très bien, et on sait que toutes remarques aussi minime soit elle peut > nous aider à faire évoluer le projet (sinon on aurait arrêté ca r le SM > ce n'est pas pour nous ;-)). > > >> Bon dev. >>
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
"VincentC" <VNO.SPAM_perso@free.Fr> writes:
Daniel a présenté l'énoncé suivant :
>
> Bonsoir,
>
> "VincentC" <VNO.SPAM_perso@free.Fr> writes:
>
>> Dans son message précédent, elecoest@netcourrier.com a écrit :
>>>> 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élioratio n.
>>> Chacun donne son point de vue (avantages / inconvénients) et on pre nd
>>> la solution la plus pérenne.
>> J'avais juste apporté cette précision, pour éviter que quelques
>> parasites bien connu, ne s'accroche au thread.
>> Ca ne concerné en aucun cas, la réponse de Daniel qui était
>> pleinement
>> justifié ainsi que celles des autres participants.
>>> Tout çà pour te dire que nous allons nous pencher sur ce point :-)
>> Alors j'attend la décision avec impatience :-)
>
> En fait j'ai reformulé la question pour bien comprendre la demande.
>
> Concernant la remarque de Romain, j'ai une phrase qui me gène dans la
> définition du numéro unique dans le "temps et dans l'espace". Sinon
> merci pour le lien.
>
> Concernant l'idée du GUID pour l'identifiant unique sur la base,
> l'idée me plait bien, maintenant la question reste entière faut il
> l'implémenter dans la couche client (je pense à SQMX) ou dans la
> couche serveur avec un trigger?
>
A mon avis, ce doit être sur la couche serveur.
1- comment dis précedemment, l'accès à la base n'est pas restreint à
une application windev. Donc Plusieurs appli (windev ou non) et
utilisant ou non SQLManagerX peut être amené à écrire dans la base
(pas forcément dans les même tables, mais on ne sait jamais).
2- Si un Trigger dans la base de donnée doit créér des enregistreme nts
dans une table ayant cette id automatique, il faut lui apprendre à
construire un id automatique ...
Pour moi, étant donné que l'id caractérise l'enregistrement de la b ase
de données ** indépendamment ** des applications qui l'utilise, c'est
au serveur d'implémenter le mécanisme quand il le peut.
Comment faire quand une base de donnée ne contient pas de type GUID
A la limite peut être le gérer soi même cf
http://www.ietf.org/rfc/rfc4122.txt
qui est très intéressant
natif ou ne gére pas les trigger ?
si pas de trigger on change de base ;-), ou voir si implémentable en
fonction possible.
Aujourd'hui même MySQL gère les triggers.
On a tout de même le choix entre Firebird, Postgresql, SQLserver,
Sybase, Oracle, Mysql, HF...
> Concernant la remarque d'ordre général, pas de soucis on s'entend t ous
> très bien, et on sait que toutes remarques aussi minime soit elle peut
> nous aider à faire évoluer le projet (sinon on aurait arrêté ca r le SM
> ce n'est pas pour nous ;-)).
>
>
>> Bon dev.
>>
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Daniel a présenté l'énoncé suivant : > > Bonsoir, > > "VincentC" writes: > >> Dans son message précédent, a écrit : >>>> 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élioratio n. >>> Chacun donne son point de vue (avantages / inconvénients) et on pre nd >>> la solution la plus pérenne. >> J'avais juste apporté cette précision, pour éviter que quelques >> parasites bien connu, ne s'accroche au thread. >> Ca ne concerné en aucun cas, la réponse de Daniel qui était >> pleinement >> justifié ainsi que celles des autres participants. >>> Tout çà pour te dire que nous allons nous pencher sur ce point :-) >> Alors j'attend la décision avec impatience :-) > > En fait j'ai reformulé la question pour bien comprendre la demande. > > Concernant la remarque de Romain, j'ai une phrase qui me gène dans la > définition du numéro unique dans le "temps et dans l'espace". Sinon > merci pour le lien. > > Concernant l'idée du GUID pour l'identifiant unique sur la base, > l'idée me plait bien, maintenant la question reste entière faut il > l'implémenter dans la couche client (je pense à SQMX) ou dans la > couche serveur avec un trigger? >
A mon avis, ce doit être sur la couche serveur. 1- comment dis précedemment, l'accès à la base n'est pas restreint à une application windev. Donc Plusieurs appli (windev ou non) et utilisant ou non SQLManagerX peut être amené à écrire dans la base (pas forcément dans les même tables, mais on ne sait jamais). 2- Si un Trigger dans la base de donnée doit créér des enregistreme nts dans une table ayant cette id automatique, il faut lui apprendre à construire un id automatique ...
Pour moi, étant donné que l'id caractérise l'enregistrement de la b ase de données ** indépendamment ** des applications qui l'utilise, c'est au serveur d'implémenter le mécanisme quand il le peut.
Comment faire quand une base de donnée ne contient pas de type GUID
A la limite peut être le gérer soi même cf http://www.ietf.org/rfc/rfc4122.txt qui est très intéressant
natif ou ne gére pas les trigger ?
si pas de trigger on change de base ;-), ou voir si implémentable en fonction possible. Aujourd'hui même MySQL gère les triggers. On a tout de même le choix entre Firebird, Postgresql, SQLserver, Sybase, Oracle, Mysql, HF...
> Concernant la remarque d'ordre général, pas de soucis on s'entend t ous > très bien, et on sait que toutes remarques aussi minime soit elle peut > nous aider à faire évoluer le projet (sinon on aurait arrêté ca r le SM > ce n'est pas pour nous ;-)). > > >> Bon dev. >>
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
