Dans cet article


Offres d'emploi

Tags

Oracle : impact de l’obsolescence du type LONG sur le modèle de données Planisware

Oracle : impact de l’obsolescence du type LONG sur le modèle de données Planisware

Description

Le type de données LONG est un type obsolète pour les bases de données ORACLE. Il est encore présent dans les versions récentes d’Oracle pour des raisons évidentes de compatibilité mais il n’évolue plus et est destiné à disparaître à terme. Il est remplacé progressivement par les types CLOB et NCLOB. Cet article présente les impacts de l’obsolescence de ce type LONG sur le produit Planisware ainsi que des stratégies possibles de migration.

Obsolescence du type LONG

Depuis la version 8i, Oracle recommande d’utiliser les types CLOB et NLOB à la place du type LONG. Sur son site Oracle précise que ce type ne doit plus être utilisé et qu’il est encore présent pour des raisons de compatibilité.

Impact sur le produit Planisware

Le type LONG est utilisé historiquement dans le modèle de données Planisware pour un certain nombre de champs (ex. le champ HOLIDAYS de la table CALENDAR).

Champs de la table CALENDAR en P5 SP1

Champs de la table CALENDAR en P5 SP1

 

La requête SQL suivante exécutée sur le schéma applicatif Plansiware permet de lister les champs de type LONG :

select OWNER,TABLE_NAME,COLUMN_NAME from ALL_TAB_COLUMNS 
WHERE OWNER='BASE_DEV1' AND DATA_TYPE = 'LONG';

avec BASE_DEV1 le nom du schéma de base de données

Ce qui donne par exemple sur le modèle de données de P5 SP1 :

Champs de type LONG en P5 SP1

Champs de type LONG en P5 SP1

 

Tous les champs de type LONG ont été modifiés en SP3. Ils sont maintenant de type CLOB comme on peut le constater dans l’exemple suivant qui décrit la table CALENDAR en SP3 :

Champs de la table CALENDAR en P5 SP3

Champs de la table CALENDAR en P5 SP3

 

Ainsi depuis la P5 SP3 lorsque le client lourd vérifie le modèle données sur une base vierge, les champs historiquement créés en type LONG sont maintenant créés en type CLOB.

Stratégies de migration

Lors de la migration d’une base de données existante (de SP1 vers SP3) la modification du modèle de données via le client lourd ne modifiera pas le type de données des champs déjà présents en base. Pour assurer la migration de ces champs 2 stratégies peuvent être envisagées :

  • Migration des données directement en base (à l’aide de la fonction TO_LOB)
  • Migration des données via un import/export de dpx :
    • export de la base (contenant des champs de type LONG) sous forme de dpx
    • suppression des tables P5 du schéma de la BDD Oracle (car sinon les tables ne sont pas recréées et les champs de type LONG pas mis à jour)
    • recréation des tables P5 via le client lourd P5 SP3 (lors la vérification du modèle physique)
    • import du dpx via le client lourd dans le schéma ainsi mis à jour

 

 

L'équipe AXOPEN

Voir aussi les articles suivants

Description La gestion de la configuration est un sujet majeur pour tout intégrateur de la solution Planisware. En effet, il convient d’être très rigoureux pour éviter tout problème (oublis d’objets de paramétrage, régressions etc.) lors de la livraison d’une nouvelle version d’une application sous Planisware. Dans cet article nous ne traiterons pas de la gestion de configuration Planisware à proprement parler. Ce sujet fera l’objet d’un article dédié. Il s’agit ici simplement de détailler les informations nécessaires à la bonne intégration des développements livrés dans le système d’information du client.
Lire l'article

Description Dans certains cas, lorsque l’on n’a pas positionné d’offset pour les différentes bases de données d’une application Planisware par exemple, on peut constater la présence d’objets ayant le même ONB dans des tables Planisware distinctes. Ceci est une corruption mineure du modèle de données car les données ne sont pas de la même classe. dans un autre article. Requête SQL Pour commencer, il faut récupérer la liste des tables Planisware possédant une colonne « ONB » (Cf.
Lire l'article

Audit de données : vérifier l’absence de doublons (ONB identiques) dans chaque table P5
Description Dans certains cas, lorsque l’on n’a pas positionné d’offset pour les bases de données Planisware par exemple, il peut arriver que l’on constate la présence d’objets ayant le même ONB dans une même table Planisware. Ceci est une grave corruption du modèle de données car Planisware ne sera pas en mesure de charger les 2 objets. Il en chargera un seul sur les 2 et la plupart du temps remontera une erreur indiquant que l’objet xxxx possèdant le même ONB que l’objet yyyy n’a pu être chargé.
Lire l'article