Conversion directe V2 vers V17

Bonjour,

Je viens d’acheter la V17 qui prendra directement la suite de V12. D’après ce que je vois, ça veut bien, du moins a priori, et moyennant quelques petites corrections.

Ce qui m’a surpris tout de même, dans l’explorateur d’exécution, côté process, c’est qu’on peut comme avant réactiver manuellement un process suspendu, mais pas un process endormi (V17 mac monoposte).

Une chose semble vouloir s’imposer, tandis que je n’en ai pas l’usage, c’est le dispositif d’historique, contraignant à la déclaration de champs uniques, indexés et incrémentés, juste pour cet usage. Il semble falloir absolument des clés primaires.

Je souhaiterais le désactiver, afin notamment qu’il m’épargne le panneau au démarrage “Des problèmes liés aux clés primaires ont été constatés, veuillez contacter le développeur”.

En structure V17 j’ai décoché table par table la ligne “Inclure dans le fichier historique”.

Dans préférences, j’ai décoché “Utiliser le fichier historique”.

Mais rien à faire, ce panneau “Des problèmes liés aux clés primaires ont été constatés, veuillez contacter le développeur” persiste à vouloir me faire faire ce dont je n’ai pas envie ni besoin ?

Que peut-il bien y avoir comme solution ?

Bonne journée ou fin de journée selon, et grand merci d’avance pour toute bonne piste à explorer.

: Franck FAISANT

Une chose semble vouloir s’imposer, tandis que je n’en ai pas
l’usage, c’est le dispositif d’historique, contraignant à la
déclaration de champs uniques, indexés et incrémentés, juste pour cet
usage. Il semble falloir absolument des clés primaires.
[…]
Mais rien à faire, ce panneau […] persiste à vouloir me faire faire
ce dont je n’ai pas envie ni besoin ?
Bonjour Franck,
l’absence de clé primaire, “en général”, ça se tient. Mais dans le 4D d’aujourd’hui, ça revient à enlever une roue à la bagnole. Deux exemples :
• avec le fichier d’historique et le backup, en cas de crash avec un data endommagé, 4D propose de :

  • restituer le backup
  • intégrer l’historique
  • repartir comme si de rien n’était
    Ça demande un clic, quand ça arrive chez le client utilisateur c’est rudement sécurisant et beaucoup plus simple qu’avant…
    • tu peux dire au revoir à ORDA car dans ce dernier, une entité (~enregistrement) n’a guère de sens https://doc.4d.com/4Dv17R5/4D/17-R5/Entites.300-4163770.fr.html#3777690sans clé primaire>

Bonjour,

: Franck FAISANT

Mais rien à faire, ce panneau “Des problèmes liés aux clés primaires
ont été constatés, veuillez contacter le développeur” persiste à
vouloir me faire faire ce dont je n’ai pas envie ni besoin ?

Ce message indique probablement un (ou plusieurs) index déclaré unique et pour lequel il existe des valeurs en double (ou plus).

Je vous conseille de passer le MSC, de vérifier l’unicité de valeur des index déclarés unique en structure.

Cela n’a rien à voir avec la journalisation que vous avez d’ailleurs désactivée.

Bonjour Arnaud,

Cette base est un serveur web autonome, qui prend en charge tous les streams entrants, alimentés par des process écoutant sur 80 et sur 443. Une pile d’enregistrements accumule ces streams et les distribue selon leur priorité aux process de traitement, ou les supprime s’il s’agit de connexions hostiles.

Aucun de ces enregistrements n’a vocation à vivre plus de quelques millisecondes. Les nombreux essais que j’ai faits m’ont montré que le coeur du gestionnaire d’enregistrement 4D est le seul qui garantisse l’intégrité de ces données, notamment grâce aux ensembles et aux sémaphores. Bien qu’en une journée il puisse passer jusqu’à 600.000 enregistrements par cette table, sa vocation est qu’il n’y en ait jamais aucun en attente de traitement. Cette table ne peut être que vide à l’ouverture de la base.

Une fois par jour les tables recevant les archives de ces activités, robots, humains, pirates, sont blobées puis vidées. La base auto zippe chaque fin de journée son data d’environ 4GO, et le range dans un disque externe, puis d’auto redémarre.

Ce type d’archivage me convient.

Quelques tables portent en effet des écritures comptables, qui mériteront une attention particulière et seront certainement les champs d’apprentissage d’ORDA et de la puissance promise.

Mais j’aimerais choisir moi-même les endroits où je devrai porter cette attention.

Bonjour Monsieur DE LACHAUX,

Merci pour cette piste intéressante.

Un balayage sur toute la structure a montré un seul champ déclaré unique, que j’ai donc manuellement désactivé. C’est toujours du code qui me garantit l’unicité à la création des enregistrements.

Mais malheureusement, au démarrage j’ai toujours ce panneau “Des problèmes liés aux clés primaires ont été constatés, veuillez contacter le développeur”.

J’ai vérifié dans les préférences, la ligne “Utiliser le fichier d’historique” que j’ai donc décochée, se trouve dans un bloc de paramétrages qui s’appelle “Lors de la création d’une nouvelle base”.

Il n’y aurait donc pas d’option possible sur une base existante.

À priori je n’ai pas de solution.

Et ça me fait peur.

Si je vous suis, je pense que ce n’est pas la bonne case que vous décochez. Il faut aller dans les paramètres de la sauvegarde.

[]30962177;“C’est l’utilisation du log pour la base courante qu’il faut décocher…”[/]

Re bonjour,

Cette case était également décochée dans les paramètres de sauvegarde lors de ces tests.

Et après vérification le résultat est le même.

Ah j’y pense, quelques champs encore en alpha indexés écarteront peut-être certaines causes de problèmes. Je m’y attèle.

Mais la doc ne dit pas que les champs alpha sont obsolètes, contrairement aux variables et compilateurs c_alpha ou tableau alpha.

Il n’y a plus ni variables ni tableaux alpha, mais les champs alpha ne sont pas obsolètes du tout (sinon je serais très malheureux).

À ma connaissance, 4D gère 3 formats de stockages de chaines :

  • 1 dans l’enregistrement
  • 2 dans le data
  • 3 hors du data
    Le champ “de type alpha” semble n’être qu’une variante du 1 dont 4D se bornerait à tronquer ce qui dépasse de la longueur spécifiée.

Ce n’est effectivement pas une bonne idée de passer tous champs alpha en texte, rien que pour voir si ça arrange mon affaire.

Mais j’ai plus de 100 tables dans cette base, et cela ne m’arrange pas non plus d’avoir à déclarer un champ uniquement parce qu’il est indispensable à un dispositif dont je n’ai pas besoin.

Je passe aujourd’hui de V12 en V17 exclusivement pour des raisons de parc machines et leurs systèmes.

Et je vois s’approcher une jolie galère.

Mais j’ai plus de 100 tables dans cette base, et cela ne m’arrange
pas non plus d’avoir à déclarer un champ uniquement parce qu’il est
indispensable à un dispositif dont je n’ai pas besoin.
En termes de développement, c’est assez neutre : l’assistant créé un champ du type demandé.
En termes d’impacts possibles :

  • comme par clé ajoutée on a un champ et un index de plus, on peut avoir un doute sur les performances avant/après, mais ça se mesure facilement
  • les code du genre “Boucle($i;1;Lire numéro dernier champ)” à vérifier
    à part ça, je vois pas trop.

Bonjour,

Est-ce que tu as des champs avec la propreté unique sans index ? Ca fait une erreur depuis 4D v13.4 je crois

Bonjour Bruno,

Non, il n’y a plus un seul champ unique dans cette base, fut il indexé ou pas.

Merci.

J’ai tenté aussi de récupérer le data enregistrement par enregistrement avec le CSM, mais le résultat est le même.

Cette conversion sent l’échec à plein nez.

Comme si j’avais besoin d’un problème supplémentaire.

Il me reste à trouver quelque part le dictionnaire des prières chamaniques.

Ou peut-être à tout laisser tomber.

12 à 17, ^tes-vous passé par les versions intermédiaire ?

Si tu penses à une corruption d’enregistrement(s), tu as la possibilité de tout exporter en SQL avec SQL EXPORTER BASE/SELECTION, puis de tout ré importer dans un data vide avec SQL EXECUTER SCRIPT. J’ai des routines qui le font, au besoin.
On peut aussi préparer la v12 en amont de la conversion pour que les $*@& clés primaires soient déjà en place quand on migre sur la version qui les requiert. J’ai toujours fait comme ça et n’ai jamais été embêté.

Salut,

Ce composant prépare la migration:

http://forums.4d.com/Post/FR/16089033/1/16089034http://forums.4d.com/Post/FR/16089033/1/16089034>

Bonjour,

Non, je suppose possible le passage direct de V12 à V17, à défaut d’un document guide.

Il y a un peu plus de dix ans, j’avais trouvé un document très précieux, produit par quelqu’un de chez 4D dont je suis désolé d’avoir oublié le nom, qui expliquait fort bien un plan de conversion de v2003 à V11, en deux ou trois phases ej crois.

Mais là pour V12 > V17, je n’ai rien trouvé, mais peut-être ai-je mal cherché, mais je suis très volontiers preneur.

En tout cas, la vie semble promettre d’être plus compliquée si je ne cède pas à l’injonction d’une clé primaire par table, que j’en aie ou non besoin.

: Franck FAISANT

Mais là pour V12 > V17, je n’ai rien trouvé, mais peut-être ai-je mal
cherché, mais je suis très volontiers preneur.

https://livedoc.4d.com/Conversion-en-4D-v17-17.1/Conversion-en-4D-v17.100-4091984.fr.html