La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Harpège Version 1.11.2 Formations techniques Décembre 2004.

Présentations similaires


Présentation au sujet: "Harpège Version 1.11.2 Formations techniques Décembre 2004."— Transcription de la présentation:

1 Harpège Version Formations techniques Décembre 2004

2 TITRE 1 Programme

3 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 journée

4 La migration informatique

5 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

6 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

7 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é-requis

8 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 1ère phase : migration vers MIG_TEST 2ème phase : migration de MIG_TEST vers HARP_ADM

9 Première phase : migration vers MIG_TEST Chargement de MIG_TEST :  fichiers plats  à partir d’application(s) locale(s)  à partir des données nationales (agora, poppee ==> scripts dpate)

10 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 vers MIG_TEST

11 Analyse des données locales 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

12 Analyse des données locales Problè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

13 Chargement de MIG_TEST à partir de la migration DPATE

14 Outil de migration DPATE è AGORA : Aide à la Gestion Optimisée des Ressources Atos è POPPEE ITARF è POPPEE Bibliothèque Chargement de MIG_TEST à partir des données nationales : migration DPATE

15 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é-requis

16 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 base et objectifs

17 Scripts complémentaires pour les données POPPEE è Situation de famille Célibataire par défaut è Transcodification des grades DPATE è … Migration DPATE : données POPPEE

18 Migration DPATE : scripts POPPEE

19 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 : traitements

20 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 - Chargement des données

21 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 - DPATE -> Mig_test

22 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 - Outil d’édition de statistiques

23 Chargement de MIG_TEST avec des fichiers plats

24 user : MIG_TEST tables des données à migrer, tables temporaires, images des tables d’Harpège Source de données existante Chargement de MIG_TEST avec des fichiers plats Ensemble de fichiers plats 1/ Extraire2/ Chargement 3/ Analyse des erreurs 4/ Mises à jour 5/ Détermination de l ’erreur 6/ Mises à jour

25 Dé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

26 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 plats

27 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 MIG_TEST : Utilisation de liens ODBC

28 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_TEST à partir des données locales Tables de transcodage Mapping entre modèles de données Initialisation des champs obligatoires Transcodages SQL

29 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.

30 Présentation du TP partie 1

31 1ere phase : Des fichiers plats vers MIG_TEST - Schéma gé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

32 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

33 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

34 Des fichiers plats vers MIG_TEST : Utilisation de SQL*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

35 SQL Loader - Principe de fonctionnement Fichier plat Fichier de contrôle (.ctl) SQL*Loader Données chargées Enregistrements erronés (optionnel) Fichier.log Enregistrements rejetés (optionnel)

36 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 fichiers de contrôle

37 SQL Loader - Lecture des fichiers 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 »

38 SQL Loader - Lecture des donné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

39 SQL Loader - Traitement des rejets Mettre à jour les enregistrements erronés dans les fichiers plats Relancer SQL Loader, les fichiers.log précédents seront écrasés

40 Présentation du TP partie 2

41 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

42 SQL 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 )

43 Migration de MIG_TEST vers HARP_ADM

44 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 1ère phase : migration vers MIG_TEST 2ème phase : migration de MIG_TEST vers HARP_ADM

45 2eme phase : de MIG_TEST vers 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

46 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 - Pré-requis

47 De MIG_TEST vers HARP_ADM - Principe de fonctionnement batch user : MIG_TEST user : HARP_ADM lecture suppression insertion table des rejets rejet règle de gestion nomenclature contraintes 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

48 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 - Activation - désactivation des contraintes

49 De MIG_TEST vers HARP_ADM - Migration 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

50 Le batch de migration : les 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

51 Le batch de migration : les composants et leur ordonnancement Un composant regroupe toutes les informations liées à un domaine précis d’Harpège Ex. : ind_eat correspond à la saisie d'un individu Tables impactées : INDIVIDU, ADRESSE_PERSONNELLE, INDIVIDU_TELEPHONE, INDIVIDU_E_MAIL, INDIVIDU_DIPLOMES

52 Mise en œuvre du batch de migration  C omposant par composant  E n 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 composants et leur ordonnancement

53 Agent Poste Occupation / Affectation Individu Position Carrière CongésModalités Emploi STRUCTURESSTRUCTURESSTRUCTURESSTRUCTURES IMPLANTATIONS LOCAUX Contrat CongésModalités Contractuels Fonctionnaires et assimilés Batch de migration : ordonnancement

54 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,4 CGA_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,1 CGA_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 : ordonnancement

55 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 - Traitement des rejets

56 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 - Traitement des rejets

57 Le batch de migration : outil d’é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 »

58 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 - Vérification de la structure d ’affectation principale

59 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

60 Suppression 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

61 Présentation du TP partie 3

62 De MIG_TEST vers HARP_ADM - 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) : Vérification structure d’affectation :

63 Documentation

64 La 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

65 La 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

66 Partie serveur :Application en version Nomenclature en version Partie cliente :Application partie cliente en version Documentation technique :1. Manuel d'installation 2. Manuel d ’exploitation 3. 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 Utilisateur 2. Manuels de formation Contenu du CD-ROM

67 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-ROM

68 Livraisons à venir Base de formation gestion collective

69 Présentation de l’Espace des Produits  è consultation des fiches assistances è documentation en ligne è ftp.amue.fr (login harpread) Assistance pour un problème : è d’installation : è de migration :

70 Merci de votre attention

71 Solutions

72 Solution : 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

73 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

74 Pré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

75 Création d’une source de donné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

76 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

77 Import des données dans 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.

78 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

79 Préparation du fichier de contrôle Préparation du fichier de contrôle associé  form_adres_perso.ctl LOAD DATA INFILE FORM_ADRES_PERSO.HA INTO 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 )

80 Lancement de SQL*Loader sqlldr mig_test/mig_test control=FORM_ADRES_PERSO.ctl log= FORM_ADRES_PERSO.log errors= Traitement des erreurs vi FORM_ADRES_PERSO.log vi FORM_ADRES_PERSO.bad Lancement de SQL*Loader


Télécharger ppt "Harpège Version 1.11.2 Formations techniques Décembre 2004."

Présentations similaires


Annonces Google