harpège version 1.11.2 formations techniques décembre 2004
TRANSCRIPT
HarpègeVersion 1.11.2
Formations Formations techniquestechniques
Décembre 2004
TITRE 1TITRE 1ProgrammeProgramme
Migration DPATE …………………………...9h00
Migration Personnelle GRH, GPU + TP 1 ..9h30
Pause .…………………………….10h30
Mise en œuvre du TP 2 …………………….10h45
Repas …………………………….12h00
Migration mig_test ………………………….13h45
Mise en œuvre du TP 3 ……………………..14h15
Question Réponse …………………………...15h15
Conclusion …………………………………...15h45
Programme de la deuxième Programme de la deuxième journéejournée
La migration La migration informatiqueinformatique
La migration informatiqueLa migration informatique
Schéma MIG_TEST
Schéma HARP_ADM
Mig_btch.sql
(procédures pl/sql)
Schéma DPATE
AGORA, POPPEE
Chgt_tab.sh(sqlloader)
Dpt_btch.sh(procédure)
Données perso(GRH, GPU, …) Transfert
personnel
Plan de l’exposéPlan de l’exposé
•Pré-requis
•Les deux phases de la migration
•Première phase : migration données locales -> MIG_TEST
Analyse des données locales Chargements des données dans MIG_TEST
avec les données nationales (AGORA, POPPEE …) avec fichiers plats
•Deuxième phase : migration MIG_TEST -> base Harpège
Mise en œuvre de l’outil de migration
Le site a créé une instance Oracle avec l’utilisateur MIG_TEST, propriétaire des tables temporaires
Le site dispose d’une source de données fiable
Le site a décidé d’une stratégie de reprise : niveau des données à migrer
Le site a effectué des enquêtes pour compléter les informations manquantes
Pré-requisPré-requis
Outil de migration
user : MIG_TEST
tables des données à migrer, tables temporaires, images des tables d’Harpège
user : HARP_ADM
tables Harpège
Source de données existante
travail de migration
vers MIG_TEST
Les deux phases de la migration Les deux phases de la migration
1ère phase : migration vers MIG_TEST
2ème phase : migration de MIG_TEST vers
HARP_ADM
Première phase : migration vers Première phase : migration vers MIG_TEST MIG_TEST
Chargement de MIG_TEST : fichiers plats
à partir d’application(s) locale(s)
à partir des données nationales (agora, poppee ==> scripts dpate)
Travail d’équipe indispensable entre le gestionnaire et l’informaticien
Identification des informations à renseigner
Création de tables de correspondance
Respect des règles de gestion
Remplir les tables temporaires de MIG_TEST avec les informations obligatoires d’Harpège
Faciliter au maximum l’étape de migration vers Harpège
Préparation de la migration Préparation de la migration vers MIG_TESTvers MIG_TEST
Analyse des données Analyse des données localeslocales
Etude du modèle de données local
quels sont les concepts (objets) modélisés ?
quelles sont les nomenclatures utilisées ?
quelles sont les clefs, les champs obligatoires ?
quelles sont les règles de gestion
exprimées dans le modèle : unicité, foreign key, ...
vérifiées par l ’application
Comparer chacun de ces points avec le modèle de données d’Harpège
Analyse des données Analyse des données localeslocales
Problèmes rencontrésProblèmes rencontrés Informations obligatoires différentes, champs manquants. Ex. type d ’accès à un corps ou à un grade
Même concept, mais nomenclatures différentes. Ex. les diplômes
Le même nom ne signifie pas la même chose dans les deux modèles. Ex. les positions statutaires
Utilisation floue ou laxiste des concepts. Ex. positions statutaires,modalités de service, congés, …
Pas de distinction entre emploi et postes
Séparation pas toujours nette entre les attributs des agents et les attributs des emplois
Chargement de Chargement de MIG_TEST à MIG_TEST à partir de la partir de la
migration DPATEmigration DPATE
Outil de migration DPATE
AGORA : Aide à la Gestion Optimisée des Ressources Atos
POPPEE ITARF
POPPEE Bibliothèque
Chargement de MIG_TEST à Chargement de MIG_TEST à partir des données nationales : partir des données nationales :
migration DPATEmigration DPATE
Récupérer les fichiers plats auprès du rectorat ou de la DPATE
Création d’un nouvel utilisateur DPATE, propriétaire des tables images d’Agora et de Poppee contenant les données à migrer.
Migration DPATE : pré-requisMigration DPATE : pré-requis
Permettre aux gestionnaires de récupérer les informations relatives à la population des agents ATOS, ITARF et Bibliothèque en poste dans l’établissement au moment de la migration.
Les IATOS contractuels ne sont pas prévus dans cette migration.
Intérêt d’une telle reprise à estimer : rapporter le temps passé consacré à cette reprise à la richesse des informations contenues dans le fichier.
Migration DPATE : principes de Migration DPATE : principes de base et objectifsbase et objectifs
Scripts complémentaires pour les données POPPEE
Situation de famille Célibataire par défaut
Transcodification des grades DPATE
…
Migration DPATE : données Migration DPATE : données POPPEEPOPPEE
FichiersDPATE (*)
Procédure DPATE Migration
Générique Spécifique POPPEE
DPATE
MIG_TEST
HARP_ADM
Complément d’installation POPPEE
Procédure de migration
Chargement tables DPATE
Préparation données DPATE
Préparation données MIG_TEST
Chargement tables MIG_TEST
Migration DPATE : scripts Migration DPATE : scripts POPPEEPOPPEE
Chargement des données DPATE (SQL Loader)
Procédures PL/SQL : Lancement de toutes les procédures par un script
Les agents IATOS sont comparés aux agents déjà dans la base sur l’homonymie
Traitement des rejets
Un outil de statistique permet d’éditer le taux de réussite dans le remplissage des informations dans MIG_TEST
Suppression de l’utilisateur DPATE
Migration DPATE : traitementsMigration DPATE : traitements
Un contrôle d ’homonymie est mis en place pour les agents ATOS déjà présents dans la base Harpège afin de permettre un rapprochement avec les informations venant d’Agora ou de Poppee.
Chargement des fichiers plats Agora et Poppee
Principe de fonctionnement de SQL*Loader
Le script chgt_tab charge les données fournies par le rectorat et le ministère dans les tables de l ’utilisateur DPATE
../MIGRATION/dpate/script/chgt_tab « mot_de_passe_Dpate » « nom_instance»
Migration DPATE -Migration DPATE -Chargement des données
Procédures Pour respecter la hiérarchie des composants de la migration, lancer les procédures de migration DPATE avec le script ../MIGRATION/dpate/script/dpt_btch.sql
Les rejets sont stockés dans la table REJET avec pour chacun le nom de la table, le rowid, la cause du rejet, le composant
Traitement des rejets Ouvrir une session SQL
Visualiser les enregistrements rejetés avec la requête suivante Select * from Nom_table where rowid = ‘ ……… ’;
Migration DPATE -Migration DPATE -DPATE -> Mig_test
Un outil de statistique permet d’éditer le taux de réussite dans le remplissage des informations dans MIG_TEST
Après chaque utilisation du batch de migration lancer :../MIGRATION/dpate/stat/dpt_btch_stat « mot_passe_DPATE » « nom_instance »
Suppression de l’utilisateur DPATE
Migration DPATE -Migration DPATE -Outil d’édition de statistiques
Chargement de Chargement de MIG_TEST avec MIG_TEST avec
des fichiers platsdes fichiers plats
user : MIG_TEST
tables des données à migrer, tables temporaires, images des tables d’Harpège
Source de données existante
Chargement de MIG_TESTChargement de MIG_TESTavec des fichiers plats avec des fichiers plats
Ensemble de fichiers plats
1/ Extraire 2/ Chargement
3/ Analyse des erreurs
4/ Mises à jour
5/ Déterminationde l ’erreur
6/ Mises à jour
Définition des fichiers platsDéfinition des fichiers plats
Un fichier plat doit correspondre à :
une table de MIG_TEST ou à un sous-ensemble de champs d’une table comprenant des champs obligatoires
un ensemble de champs, éventuellement vides, de longueur fixe ou délimités par un séparateur
Les fichiers plats sont générés en utilisant la
fonction exportation de l’application locale
Le formatage des fichiers plats est à la charge des établissements avec l’outil de leur choix
Les fichiers plats doivent tenir compte :
des champs obligatoires - cf MPD Harpège -
du type des données - cf. MPD Harpège -
des nomenclatures Harpège - tables de correspondance -
Préparation des fichiers platsPréparation des fichiers plats
Préparation des fichiers plats
(séparateurs)
Formatage des fichiers plats avec les
outils bureautiques
Création du lien ODBC entre Access et
MIG_TEST
Activation des contraintes d’intégrités
Import des données dans MIG_TEST
Traitement des anomalies
Des fichiers plats vers Des fichiers plats vers MIG_TEST : Utilisation de liens MIG_TEST : Utilisation de liens
ODBCODBC
user : MIG_TEST
tables des données à migrer, tables temporaires, images des tables d’Harpège
Source de données existante
Chargement direct de MIG_TESTChargement direct de MIG_TESTà partir des données localesà partir des données locales
Tables de transcodage
Mapping entremodèles de données Initialisation des champs obligatoires Transcodages
SQL
Schéma général : les 2 phases de la migration
1ère phase : des fichiers plats vers MIG_TEST
Utilisation de liaison ODBC
Utilisation de SQL Loader
2ème phase : de MIG_TEST vers HARP_ADM
Utilisation du batch
Analyse des statistiques et des rejets
Présentation du T.P.Présentation du T.P.
Présentation du Présentation du TP partie 1TP partie 1
1ere phase : Des fichiers plats 1ere phase : Des fichiers plats vers MIG_TEST - Schéma vers MIG_TEST - Schéma
généralgénéral
Fichiers plats
Liaisons ODBC
batch
user : MIG_TEST
tables des données à migrer, tables temporaires, images des tables d’Harpège
user : HARP_ADM
tables Harpège
Activation des contraintes d’intégrités
SQL*Loader
Liaison ODBC : énoncé Liaison ODBC : énoncé
Migration des fichiers plats form_individu.txt
form_diplome.txt
Formatage des fichiers plats (outils bureautiques)
Vérification de la structure
Formatage des données
Gestion des correspondances simples
Création du lien ODBC entre Access et MIG_TEST
Activation des contraintes d’intégrité (enable.res)
Import des données dans MIG_TEST Gestion des tables de correspondances
Gestion de la table des erreurs
Liaison ODBC : les outils Liaison ODBC : les outils
Le Modèle Logique des Données Harpège Domaine individu - cf Annexes -
La description des tables du domaine individu de MIG_TEST et d’HARP_ADM
Structure des tables
Tables de nomenclature d ’Harpège
Des fichiers plats vers Des fichiers plats vers MIG_TEST : Utilisation de MIG_TEST : Utilisation de
SQL*LoaderSQL*Loader
Principe de fonctionnement
Mise en œuvre : Préparation des fichiers plats
Préparation des fichiers de contrôle
Lancement de SQL*Loader
Traitement des rejets
SQL Loader - Principe de SQL Loader - Principe de fonctionnementfonctionnement
Fichier plat
Fichier de contrôle
(.ctl)
SQL*Loader
Données chargées
Enregistrements erronés
(optionnel)
Fichier
.log
Enregistrements rejetés
(optionnel)
Les fichiers de contrôle définissent la structure des données contenues dans les fichiers plats
2 possibilités pour faire la description des fichiers plats :
par position => la longueur des champs est fixe
à l’aide d ’un séparateur => la longueur des champs peut-être variable
Voir exemple en annexe et documentation SQL Loader - Oracle Server Utilities -
SQL Loader - Préparation des SQL Loader - Préparation des fichiers de contrôlefichiers de contrôle
SQL Loader - Lecture des SQL Loader - Lecture des fichiers platsfichiers plats
La commande de lancement de SQL Loader permet d ’indiquer le nom et chemin :
du fichier de contrôle
du fichier log
du nombre maximum d ’erreurs
… cf doc ORACLE8 - Server Utilities
sqlldr user/mot_de_passe control=« nom et chemin du fichier de contrôle » log=«nom et chemin de sauvegarde du fichier log » errors=« nombre maximum d ’erreurs »
SQL Loader - Lecture des SQL Loader - Lecture des donnéesdonnées
Seuls les enregistrements dont l ’intégralité des données est correcte sont importés dans les tables de MIG_TEST
SQL Loader rejette les enregistrements qui génèrent une erreur ORA-
pour lesquels les données sont incorrectes - formatage -
Les enregistrements sont rejetés en totalité dans le fichier .bad - les données le constituant ne sont insérées dans aucune table -
La cause du rejet est enregistrée dans le fichier .log
SQL Loader - Traitement des SQL Loader - Traitement des rejetsrejets
Mettre à jour les enregistrements erronés dans les fichiers plats
Relancer SQL Loader, les fichiers .log précédents seront écrasés
Présentation du Présentation du TP partie 2TP partie 2
SQL Loader - EnoncéSQL Loader - Enoncé
Migration du fichier plat form_adres_perso.ha
Préparation du fichier de contrôle associé form_adres_perso.ctl
Lancement de SQL*Loader
Traitement des erreurs
SQL Loader - les outilsSQL Loader - les outils
Le Modèle Logique des Données Harpège Domaine individu
La description des tables du domaine individu d ’Harpège
Structure des tables
Tables de nomenclature d ’Harpège
Documentation Oracle8 Server Utilities (dont SQL*Loader )
Migration de Migration de MIG_TEST vers MIG_TEST vers
HARP_ADMHARP_ADM
Outil de migration
user : MIG_TEST
tables des données à migrer, tables temporaires, images des tables d’Harpège
user : HARP_ADM
tables Harpège
Source de données existante
travail de migration
vers MIG_TEST
Les deux phases de la migration Les deux phases de la migration
1ère phase : migration vers MIG_TEST
2ème phase : migration de MIG_TEST vers
HARP_ADM
2eme phase : de MIG_TEST 2eme phase : de MIG_TEST vers HARP_ADMvers HARP_ADM
Pré-requis
Principe de fonctionnement
Activation et désactivation des contraintes
Migration des composants
Traitement des rejets - statistiques
Vérification de la structure d ’affectation principale
Mise à jour des séquences
Suppression de Mig_test
Le site a créé une instance Oracle avec 2 utilisateurs :
MIG_TEST propriétaire des tables à migrer HARP_ADM propriétaire des tables d’Harpège
Le site a inséré dans MIG_TEST les données à migrer avec une méthode qui lui est propre
Le paramétrage doit être saisis dans les tables d’HARP_ADM
(10 tables concernées : PARAM_ETABLISSEMENT, ORGANISME_RECHERCHE, ORG_MISSION,ANNEE_UNIVERSITAIRE, IMPLANTATION_GEO, TELEPHONE, STRUCTURE, ADRESSE_ADMINISTRAT, LOCALISATION_STRUCTURE, LOCAL)
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Pré-requisPré-requis
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Principe de fonctionnementPrincipe de fonctionnement
batch
user : MIG_TEST user : HARP_ADM
lecture
suppressioninsertion
table des rejets
rejet
règle de gestion
nomenclaturecontraintes d’intégrités
Traitement d’un enregistrement Lecture Contrôle de cohérence si erreur alors traitement rejet sinon insertion dans d’HARP_ADM et suppression de MIG_TEST
1°) Activation des contraintes sur MIG_TEST : les données à migrer vérifient bien toutes les contraintes d’intégrité (clé primaire, clé étrangère, clé unique, domaine de valeur) : enable.res
2°) Désactivation des contraintes sur MIG_TEST afin de pouvoir migrer les données: disable.res
La migration des données ne sera cohérente que si les 2 étapes d’activation et de désactivation des contraintes dans MIG_TEST se sont déroulées sans problème
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Activation - désactivation des Activation - désactivation des
contraintescontraintes
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Migration des composantsMigration des composants
La migration peut-être lancée de 2 façons sous l ’utilisateur MIG_TEST :
migration des composants un à un -vivement recommandé -. Pour cela exécuter sous SQL : execute « nom_du_composant »
Respecter la hiérarchie des composants
migration de l ’ensemble des composants exécution du batch : ../MIGRATION/mig_harpege/script/mig_btch.sql
Le batch de migration : les Le batch de migration : les traitements traitements
Ensemble de procédures PL/SQL exécutées dans un ordre précis
Ces procédures lisent et contrôlent les données des tables de MIG_TEST puis les déversent dans HARP_ADM
Un enregistrement n’est déversé que s’il est entièrement correct, sinon un enregistrement de rejet est généré, avec code et motif du rejet
Ce déversement est suivi d’une suppression dans MIG_TEST de l’enregistrement déversé
L’objectif est d’obtenir des tables de MIG_TEST vides et leurs correspondantes HARP_ADM remplies
Le batch de migration : les Le batch de migration : les composants et leur composants et leur ordonnancementordonnancement
Un composant regroupe toutes les informations liées à un domaine précis d’HarpègeEx. : ind_eat correspond à la saisie d'un individu
Tables impactées : INDIVIDU, ADRESSE_PERSONNELLE, INDIVIDU_TELEPHONE, INDIVIDU_E_MAIL, INDIVIDU_DIPLOMES
Mise en œuvre du batch de migration
Composant par composant
En une seule fois sur l’ensemble des composants (script non interactif qui se lance sans paramètre)
2 règles à respecter Toutes les tables associées à un composant doivent être remplies
La hiérarchie des composants doit être respectée
Le batch de migration : les Le batch de migration : les composants et leur composants et leur ordonnancementordonnancement
Agent
Poste
Occupation /Affectation
Individu
Position
Carrière
CongésModalités
Emploi
SS
TT
RR
UU
CC
TT
UU
RR
EE
SS
II
MM
PP
LL
AA
NN
TT
AA
TT
II
OO
NN
SS
LL
OO
CC
AA
UU
XX
Contrat
CongésModalités
Contractuels Fonctionnaires et assimilés
Batch de migration : Batch de migration : ordonnancementordonnancement
IND_EAT (1,1) PST_IDBP (1,3)EMP_MOY (1,2)
IND_STR (2,1) PER_AGT (2,2) PST_IDBE (2,3)
CAR_ELEM (3,1) PER_PAS (3,2) PER_CTR (3,3)
CAR_BIND (4,2) PER_POS (4,1)
PER_DEPA (5,2) PIL_NOTE (5,3)
CGA_CMNT (4,3)CGA_CGM (4,4CGA_NTIT (4,5)CGA_ACTR (4,6)CGA_AL3 (4,7)CGA_AL4 (4,8)CGA_AL5 (4,9)CGA_AL6 (4,10)
PER_TPS (5,4)
OCAF_PER (5,1)
CGA_MAD(6,1CGA_LIMA (6,2)CGA_SURN (6,3)CGA_MTFC (6,4)CGA_COM (6,5)CGA_ACSE (6,6)CGA_CRCT (6,7)CGA_STAG (6,8)CGA_BONI (6,9)
CGA_CPA (6,10)CGA_DELE (6,11)CGA_ADOP (6,12)CGA_FORM (6,13)CGA-MIDE (6,14)CGA_MATE (6,15)CGA_CLM (6,16)CGA_CLD (6,17)
CGA_MTTH (6,18)CGA_FACT (6,19)AFF_SSOC (6,20)
Batch de migration : Batch de migration : ordonnancementordonnancement
Tous les rejets se trouvent dans la table REJET de MIG_TEST
Un rejet est caractérisé par : le nom de la table concernée par le rejet le rowid de l’enregistrement rejeté la cause du rejet Le nom du composant concerné par le rejet
Il s’agit de comprendre les rejets pour les corriger et relancer l’opération jusqu’à l’obtention de résultat jugés satisfaisants
Une compétence fonctionnelle est indispensable pour analyser et comprendre les rejets
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Traitement des rejetsTraitement des rejets
Avant exécution de l’outil de migration, en cas de violation des contraintes d’intégrité des bases de MIG_TEST : clef primaire, clef étrangère, clef unique, domaine de valeur, …
Lors de l ’exécution de l’outil, essentiellement pour non respect des règles de gestion. Ex. succession des segments de carrière, règles de changement de corps, grade ou échelon, …
Champs obligatoires non renseignés
Peuvent aussi révéler des erreurs ou des incohérences dans la base locale
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Traitement des rejetsTraitement des rejets
Le batch de migration : outil Le batch de migration : outil d’édition des statistiquesd’édition des statistiques
Taux de réussite de HARP_ADM par table
Taux de rejet de MIG_TEST par table
Liste des rejets triés par composant
Liste des rejets triés par nombre décroissant
../MIGRATION/mig_harpege/stat/mig_btch_stat « mot_passe_MIG_TEST » « nom_instance »
Sous SQLPLUS, utilisateur MIG_TEST lancer le script : ../MIGRATION/mig_harpege/script/aff_prin.sql
Le script établie la liste des dossiers sur lesquels l’utilisateur devra déterminer la structure d’affectation principale.
Cette saisie sera effectuée directement via
l’application Harpège
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - Vérification de la structure Vérification de la structure d ’affectation principale d ’affectation principale
Mise à jour des séquences Mise à jour des séquences
Une fois toutes les données migrées, il faut mettre à jour les séquences ORACLE en fonction des données insérés dans les tables HARP_ADM
Maj_seq.ini
Suppression de MIG_TESTSuppression de MIG_TEST
Pour commencer la phase d’exploitation, une fois toutes les données migrées, il faut supprimer l’utilisateur MIG_TEST et le tablespace associé
Indispensable pour les futures mises à jour Harpège
Présentation du Présentation du TP partie 3TP partie 3
De MIG_TEST vers HARP_ADM - De MIG_TEST vers HARP_ADM - EnoncéEnoncé
Activer et désactiver les contraintes d ’intégrité
Lancement du batch du composant de migration sous SQLPLUS (mig_test) :
execute mig_ind_eat Statistiques et traitement des rejets
select * from rejet mig_btch_stat.sh mig_test
nom_instance Mise à jour des séquences ORACLE sous
SQLPLUS (harp_adm) : @maj_seq.ini
Vérification structure d’affectation : @aff_prin.sql
DocumentationDocumentation
La documentationLa documentation
Documentation livrée jusqu’à aujourd’hui : Classeur conduite de projet Dossier de paramétrage Guide de reprise de données
(méthodologie) CCI Liste des champs obligatoires
La documentationLa documentation
Documentation contenue dans le classeur : Transparents formation
installation reprise de données
Manuel d’installation de l’application Manuels d’installation outils de reprise
Partie serveur : Application en version 1.11.2.0Nomenclature en version 1.11.2.0
Partie cliente : Application partie cliente en version 1.11.2.0
Documentation technique : 1. Manuel d'installation2. Manuel d ’exploitation3. Cahier des charges d ’implantation
4. Champs obligatoires avec copies d'écrans
5. Listes des nomenclatures (.xls)6. Manuel base de formation
Documentation fonctionnelle : 1. Manuel Utilisateur2. Manuels de formation
Contenu du CD-ROMContenu du CD-ROM
Modèle de données : 1. MLD 2. MPD
Paramétrage : 1. Dossier de paramétrage
Reprise de données : 1. Migration Harpège 2. Migration Dpate
Contenu du CD-ROMContenu du CD-ROM
Livraisons à venirLivraisons à venir
Base de formation gestion collective
Présentation de l’Espace des Produits
http://www.amue.fr/
consultation des fiches assistances
documentation en ligne
ftp.amue.fr (login harpread)
Assistance pour un problème :
d’installation : [email protected]
de migration : [email protected]
ConclusionConclusion
Merci de votre Merci de votre attention attention
SolutionsSolutions
Solution : liaison ODBCSolution : liaison ODBC Ouvrir les fichiers plats sous Excel
Formater les champs dates, les champs numériques
Ajouter des colonnes
Renseigner les champs obligatoires
Préparer la liaison ODBC
Création d ’une nouvelle base sous Access Attacher les tables de MIG_TEST par ODBC (voir MLD)
Import des données Excel dans Access
Activation des contraintes d ’intégrité (enable.res)
Import des données dans MIG_TEST Gestion des tables de correspondances
Gestion de la table des erreurs
Formatage Formatage
Formater les champs dates, les champs numériques
Ajouter des colonnes, vérifier les champs nomenclature
Renseigner les champs obligatoires
Sauvegarder le fichier avec un type de fichier .xls
Préparation de la liaison ODBCPréparation de la liaison ODBC
Menu Fichier - Données externes - Lier les tables
Choisir le type de fichier : Base de données ODBC
Sélectionner ou créer la source de données
Création d’une source de Création d’une source de donnéesdonnées
Choisir le pilote Oracle
Créer la connexion - Donner le nom de l ’instance -
Se connecter avec l ’utilisateur MIG_TEST
Attacher les tables de MIG_TEST
Ouvrir une connexion sous SQL Plus - User MIG_TEST
Exécuter le script ENABLE.RES
L ’activation des contraintes permet de déclencher directement les messages d ’erreur lors de l ’ajout des enregistrements dans Access.
Activation des contraintes Activation des contraintes
Import des données dans Import des données dans MIG_TEST MIG_TEST
Importer la table Excel précédemment formatée
Créer les tables de correspondances et les requêtes de mise à jour
Exécuter les requêtes pour mettre à jour les champs de nomenclature
Sélectionner les enregistrements de la table Access
Copier par ajout dans la table de MIG_TEST correspondante
Les enregistrements rejetés sont stockés dans la table des erreurs.
Solution - SQL Loader Solution - SQL Loader
Migration du fichier plat form_adres_perso.ha
vérifier la structure de la table adresse_personnelle d ’HARP_ADM : type de données valeur nomenclatures champs obligatoires
Préparation du fichier de Préparation du fichier de contrôlecontrôle
Préparation du fichier de contrôle associé
form_adres_perso.ctlLOAD DATAINFILE FORM_ADRES_PERSO.HAINTO TABLE ADRESSE_PERSONNELLE TRUNCATE(ID_ADRESSE_PERSO POSITION(*) INTEGER EXTERNAL(7) NULLIF ID_ADRESSE_PERSO = BLANKS , NO_INDIVIDU POSITION(*) INTEGER EXTERNAL(8) NULLIF NO_INDIVIDU = BLANKS , TEM_ADR_PERS_PRINC POSITION(*) CHAR(1) NULLIF TEM_ADR_PERS_PRINC = BLANKS ,HABITANT_CHEZ POSITION(*) CHAR(32) NULLIF HABITANT_CHEZ = BLANKS ,TELEPHONE_DOMICILE POSITION(*) CHAR(25) NULLIF TELEPHONE_DOMICILE = BLANKS ,NO_VOIE POSITION(*) INTEGER EXTERNAL(4) NULLIF NO_VOIE = BLANKS ,BIS_TER POSITION(*) CHAR(1) NULLIF BIS_TER = BLANKS ,C_VOIE POSITION(*) CHAR(3) NULLIF C_VOIE = BLANKS ,NOM_VOIE POSITION(*) CHAR(22) NULLIF NOM_VOIE = BLANKS ,LOCALITE POSITION(*) CHAR(26) NULLIF LOCALITE = BLANKS ,CODE_POSTAL POSITION(*) INTEGER EXTERNAL(5) NULLIF CODE_POSTAL = BLANKS ,VILLE POSITION(*) CHAR(26) NULLIF VILLE = BLANKS ,C_PAYS POSITION(*) CHAR(3) NULLIF C_PAYS = BLANKS ,D_CREATION POSITION(*) DATE "YYYYMMDD" NULLIF D_CREATION = BLANKS , D_MODIFICATION POSITION(*) DATE "YYYYMMDD" NULLIF D_MODIFICATION = BLANKS )
Lancement de SQL*Loadersqlldr mig_test/mig_test control=FORM_ADRES_PERSO.ctl log= FORM_ADRES_PERSO.log errors=999999
Traitement des erreursvi FORM_ADRES_PERSO.log
vi FORM_ADRES_PERSO.bad
Lancement de SQL*LoaderLancement de SQL*Loader