|
FORUMS PROFESSIONNELS WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
Pb d'identifiant après suppression de Réplication |
Débuté par Gilles Monetti, 20 oct. 2017 12:26 - 7 réponses |
| |
| | | |
|
| |
Posté le 20 octobre 2017 - 12:26 |
Bonjour,
Sur la table principale (appelée table dossier par la suite) j'ai un identifiant automatique sur 4 octets. qui me donne un numéro séquentiel (très important pour mon client).
J'ai mis en place un réplication monodirectionnelle de base HFSQL entre 2 serveurs. En ayant changé au préalable tous les identifiant uniques sur 8 octets et donc celui de la table dossier.
Mais après avoir mis la réplication en place, je me suis aperçu que lors des créations, les identifiants prenaient un certain nombre de caractères certainement pour avoir des identifiants uniques entre serveur. Le dernier avant réplication était 5832 et après mise en place de la réplication: on passait à 2185627866668. Ce qui n'est pas du goût de mon client car cet identifiant est important.
En éliminant la réplication je me suis dit que cela allait revenir comme avant. Et bien non!! (j'ai éliminé la réplication et bien spécifié qu'il n'était plus ni maître ni abonné)
Je n'arrive plus à retrouver une numérotation séquentielle comme avant.
Y a t'il un moyen justement pour y arriver???
qu'est-ce qui fait que maintenant il reste sur une numérotation sur plus de 10 caractères. |
| |
| |
| | | |
|
| | |
| |
Posté le 20 octobre 2017 - 18:05 |
Pour aller un petit loin dans la démarche, Quand on regarde par le centre de contrôle, les propriétés de la table en question, on s'aperçoit qu'après la mise en place de la réplication, la borne minimale de l' identifiant automatique est passée de 1 à un nombre à plus de 10 digits.
En fait si quelqu'un connaît l'astuce pour remettre cette borne minimale à 1, je pense que le problème sera réglé.... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 948 messages Popularité : +30 (92 votes) |
|
Posté le 21 octobre 2017 - 16:29 |
Coucou,
Sur la table principale (appelée table dossier par la suite) j'ai un identifiant automatique sur 4 octets. qui me donne un numéro séquentiel (très important pour mon client). => A l'avenir je te conseil d'utiliser les UUIDv4 insta au IDAUto (j'ai fait un post sur les avantages / inconvenients, est c un bon example que UUIDv4 > IDAuto dans ton cas, mais anyway, c fait c fait ^^)
J'ai mis en place un réplication monodirectionnelle de base HFSQL entre 2 serveurs. En ayant changé au préalable tous les identifiant uniques sur 8 octets et donc celui de la table dossier. <- Deux fois
Mais après avoir mis la réplication en place, je me suis aperçu que lors des créations, les identifiants prenaient un certain nombre de caractères certainement pour avoir des identifiants uniques entre serveur. Le dernier avant réplication était 5832 et après mise en place de la réplication: on passait à 2185627866668. Ce qui n'est pas du goût de mon client car cet identifiant est important. <- C'est normal, c'est un "Tips" en fait le moteur HFSQL "reserve" un range de plage pour la replication
Y a t'il un moyen justement pour y arriver??? Essaye de faire un re-index
qu'est-ce qui fait que maintenant il reste sur une numérotation sur plus de 10 caractères. <- la "reservation" de la plage pour la replication.
La prochaine fois, vire tes IDAuto et fou des UUIDv4
-- Charly CanDo - In üs we trust - #92i Do. Or do not. There is no try - #y0d4
(#Compétence & #rapidité & #implication & #references) > #PasDeCV Je suis disponible pour du consulting Windev (#debug #Optimization #System #Etc)Message modifié, 21 octobre 2017 - 16:33 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 1 298 messages Popularité : +20 (72 votes) |
|
Posté le 21 octobre 2017 - 21:42 |
| |
| |
| | | |
|
| | |
| |
Posté le 23 octobre 2017 - 10:58 |
Bonjour,
Je connais bien les hajoute avec les hforceid et hfixeid. Mais le pb n'est pas là, hélas!
Comme je l'indique dans mon 2ème message: mon pb vient du fait que la borne minimale de la table est enregistrée cf tableau ci-joint (que l'on peut voir soit avec wdmap ou soit avec le Centre de contrôle)
C'est cette borne minimale que j'aimerai vouloir revenir à 1. Mais par quel moyen? |
| |
| |
| | | |
|
| | |
| |
Posté le 10 novembre 2017 - 11:40 |
Bjr,
Charly CANDO a couché sur son écran :
La prochaine fois, vire tes IDAuto et fou des UUIDv4
Dsl, mais c 'est un peu leger pour remettre en cause la fiabilités des IDAuto .
a plus
-- ------------------------------------------------------------- www.ctc-soft.com Gestion biblo-documentaire (free-share) Comptabilité shareware Logiciels de Gestion de saisie terrain Spécialisé Tournées de boulangers ------------------------------------------------------------- |
| |
| |
| | | |
|
| | |
| |
Posté le 10 novembre 2017 - 11:43 |
Bjr,
Gilles Monetti avait énoncé :
C'est cette borne minimale que j'aimerai vouloir revenir à 1. Mais par quel moyen?
Et si tu crées un nouveau fichier, sans replic avec idauto qui demarre a 1 et tu recopie tous tes enregistrements dans le nouveau fichier. HcopieEnreg est ton ami
Attention, il ne faut pas bien sur que l'ident d'origine soit utilisé pour de relations avec d'autres fichiers, sinon c 'est plus compliqué
a plus
-- ------------------------------------------------------------- www.ctc-soft.com Gestion biblo-documentaire (free-share) Comptabilité shareware Logiciels de Gestion de saisie terrain Spécialisé Tournées de boulangers ------------------------------------------------------------- |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 14 messages |
|
Posté le 19 avril 2018 - 15:40 |
Bonjour à tous,
J'ai le même souci que Gilles, à savoir la numérotation différente de mes identifiants après mise en place d'une réplication. Sur certains fichiers, cela ne pose pas de problème, sur d'autres, c'est plus embêtant pour mon client. J'ai utilisé HForceIdAuto et/ou hFixeIdAuto pour retrouver une séquence "normale", rien n'y fait. Avez-vous trouvé une solution à ce problème ? Merci d'avance, Florence |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|