Nous avons opéré une migration en v5 ce matin. Ça ne s’est pas super bien passé mais on a un environnement qui marche a priori correctement
Le problème vient du script de migration de la BDD de p24 en v5 p00, logs ci-joints.
Les logs qui vous intéresseront le plus sont dans le fichier ligne 91 à 126 concernant la migration en P00.
Il y a des erreurs de types “already” exists dans la mesure ou il y a eu un premier deploiement en echec.
J’ai identifié 3 instructions qui posent problème:
ALTER TABLE m_object ALTER COLUMN TYPE varchar2(10), ligne 116
ALTER TABLE web_news ALTER COLUMN web_lang varchar(3) NOT NULL, ligne 120
ALTER TABLE m_field ADD COLUMN fld_speech varchar2(10), ligne 123
J’ai pu compenser les erreurs concernant les varchar en passant les requetes à la mains en utilisant un varchar(10) au lieu du varchar2.
Suite a cette migration nous avons donc un environnement de dev qui à l’air opérationnel, on a pas encore assez de recul pour voir si on a des erreurs persistantes.
Merci pour votre retour. nous attendrons vos retours pour effectuer d’autres déploiements. tentative migration BDD.csv (58.4 KB)
Oui il y a du y avoir un raté avec le patch Oracle… sur PostgreSQL la syntaxe est la suivante :
ALTER TABLE m_object ALTER COLUMN obj_srh_predef TYPE varchar(10);
ALTER TABLE web_news ALTER COLUMN web_lang TYPE varchar(3) NOT NULL;
ALTER TABLE m_field ADD COLUMN fld_speech varchar(10);
La non normalisation des ordres DDL entre les SGBDR nous pose toujours des soucis.
PS: les erreur liées au rejeu des patches SQL (genre “already exists”) peuvent être ignorées, la mécanique d’upgrade ne peut pas faire le tri entre ce qui a déjà été fait et ce qui doit encore être fait, surtout avec PostgreSQL qui ne gère pas les syntaxes “if (not) exists” pour toutes les versions supportées par Simplicité.
L’objectif du patch est de recréer l’index unique de cette table.
Historiquement (en V3) cette colonne nws_lang était optionnelle, mais Oracle refuse de créer un index unique si une colonne de l’index est null.