Historique gluant

La suite de https://forums.4d.com/Post/FR/23568469/1/26530170#23568470ce fil>.

Cas pratique : j’ai une base v15 sur un poste serveur, je veux monter la même en v17 (sur d’autres ports) pour que les utilisateurs puissent faire les tests finaux avant migration définitive. Pour que ces tests aient l’air vrais, j’utilise une copie récente du 4DD v15 (restitution de 4BK).

Et c’est là que les emmerdements commencent : quand la base v17 démarre, elle se jette sur l’historique de la v15, constate que ça a bougé entre temps et qu’il faut ABSOLUMENT réparer. J’ai essayé de plusieurs façons, mais c’est vraiment indécrottable, même le csm n’y peut rien. Pour finir, j’ai dû :

  • arrêter la v15 (profitant lâchement de ce qu’un utilisateur, à midi, part bouffer)
  • ajouter un caractère au nom du fichier journal
  • lancer la v17 qui, ne trouvant plus le journal, me permet enfin de lui dire que j’en veut un autre ou n’en ai pas besoin
  • enlever le caractère du fichier journal
  • relancer la v15

Personne n’a trouvé un moyen de dire à une base qui démarre d’oublier l’historique ? :evil:

Je trouve que cette gestion de l’historique est une sérieuse faille de la sauvegarde made in 4D : si on ne sait pas comment 4D gère ce chemin de l’historique (pas trouvé dans la doc), on peut aisément se retrouver avec deux bases qui écrivent dans le même historique (vécu).

Bis : déplacer un 4DD n’est pas anodin. A minima, quand ça arrive, 4D devrait nous demander s’il est pertinent de continuer à utiliser le même chemin d’historique.

ça rejoint le problème des prefs du backup: avec une seule structure j’ouvre plusieurs data qui n’ont rien à voir les uns avec les autres.
J’aimerais que les prefs ne soient plus coté structure mais coté data

J’ai pris l’habitude de supprimer les prefs quand je restitue un 4DD hors de sa boite backup.

Mais le problème dont je parle est autrement plus anxiogène. Il est fréquent de prendre un data de production pour effectuer des tests. Pour peu que ce data qu’on a copié ait accès, quand on l’ouvre, au chemin du journal de la base de production, on va avoir 2 cas possibles :
1/ la base de prod a évolué entretemps, la copie veut ABSOLUMENT intégrer le journal ; faute de doc, on passe un moment avant de comprendre que le chemin d’historique est stocké dans le data et que la copie s’est jetée dessus comme si sa vie en dépendait
2/ la base de prod n’a pas évolué entretemps, et là c’est le pompon : les deux bases écrivent dans le même historique !!!