Discussion :

[foulla]

bonjour,
j'ai généré à partir de Windev12, un script sql contenant la structure de ma base de données HyperFile.Ce script contient des requettes SQl qui permettent de créer une base de données vide dans Mysql .
mais le problème c'est que ce script ne traduit pas correctement la notion de "clés composée unique" de hyper file car quant il a créé la base dans Mysql on trouve que la table qui a dans HyperFile une clés composée unique n'a aucune clés dans la nouvelle base Mysql.
comment je peux régler cette anomalie de clés car il n'est pas evident qu'on se trouve à la fin ave des tables sans clés

[Gilles_69]

Salut,
as-tu un exemple à montrer de ton script SQL stp ?

A+

[Le Shadow]

Allo,

Si tu mets la clause "Order by" dans ta requete, tu vas pouvoir le savoir !!

[Gilles_69]

Ah !
J'aurais pensé qu'il fallait regarder du côté de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
CREATE [UNIQUE] INDEX Nom_de_l_index
ON Nom_de_la_table
(Nom_de_champ [ASC/DESC], ...)

A+

[foulla]

bonjour les amis,
je vais ajouter quelques explications concernant ma question:
- le script que j'ai généré à partir de windev contient tout le nécessaire ( les tables, les index, les contraintes d'integrité, les type et les tailles des éléments des tables) MAIS, il n'a pas traduit la notion de clés composée unique. je m'explique => il lit les tables de la base HF une par une et il traduit leus structures dans des requettes sql qu'il a mis dans le script mais quand il trouve une table "Client" comme ca (nomClient : text(20), adresse texte(50), test entier(12), nomClient+adresse Clés composée unique) il va traduire tout les details en code sql mais il va pas traduire le dernier élément "nomClient+adresse Clés composée unique" et je vais sortir à la fin de l'exécution du script avec une table Client avec seulement 3 champs (nomClient, adresse,tel) et sans clés primaire ou unique si on veux dire

[Firetox]

Bonjour,

les cles composées n'ont pas d'existence réelle dans un SGBDR car en fait ce sont des index unique ou non regroupant plusieurs colonnes. le probleme de HF est que pour gerer cela il crée un champs contenant les 2 colonnes separrées par un caractere (Caract(128))

les table SQL d'une SGBDR sont reliées par des primary key et si la liaison porte sur plusieurs colonne la primary key est generalement un autoIncrement et un index unique formé des deux colonnes est crée.

dans votre cas il faut lors de la generation de la table si elle contient une cle windev qui est une cle composée :

1) soit crée une colonne qui est identique mais dans l'analyse windev vous ne la lirez que dans la structure d'index. mais ce choix est a eviter car lors de l'importation des données il va falloir gerer le caract(128à

2) soit ne pas creer cette colonne mais generer un index unique sur les colonnes formant la cle composé. dans l'import des donnée vousn'aurez pas de probleme car les 2 colonnes existe il n'y a pas a reprendre la colonne cle composé , l'index de la base se chargeant des contrainte (doublon, etc ...)

Bon dev
@+

[foulla]

merci pour votre réponse
j'ai vérifié le script et j'ai remarqué que :
_ si la clés composée est une clés primaire dans HF le script la traduit pas .
_ par contre si la composée est utilisée comme clés étrangère, il la traduit en indexe avec 2 colonnes.
mais le problème est tjrs posé:
car même si je vais migrer mes données de HF vers mysql je garderais tjr le code existant de Windev12 mais avec une connexion en natif vers la nouvelle base Mysql ,en outre s'il y a une ligne dans le code de Windev qui utilise ces clés composées je pense que ça va chauffer