équivalent SQL*Loader pour FB / IB [Résolu]

[djeant]

Bonjour,

Je recherche un outils me permettant de charger des fichiers plats dans une base FB 1.5.
L'idéal serait de trouver un outils dont le fonctionnement se rapprocherais de celui du fameux SQL*Loader pour Oracle.

Est-ce que quelqu'un a déjà entendu parler d'un tel outil ?

Merci d'avance.

[Barbibulle]

Il existe pas mal d'outils pouvant le faire.
Maintenant tout dépend votre besoin.

Juste le temps d'un transfert ?
Automatisable ?

FB/Interbase savent lire certains type de fichier plat sous forme de table externe.

[djeant]

Je recherche un outil qui soit automatisabe.
Mais en plus j'aimerais pouvoir définir le format du fichier plat dans un fichier de paramettrage.

FB/Interbase savent lire certains type de fichier plat sous forme de table externe.

J'ai essayé les tables externe, mais je n'ai pas bien compris quel format devait avoir le fichier plat.
As-tu de la doc ?

[jean-jacques varvenne]

j'utilise quasi toujours les tables externes pour "entrer" les données volumineuses dans la base.

il faut pour cela, un fichier colonnés terminé par un CR/LF ou LF seul, cela n'est pas indispensable, mais cela simplifie la vie lorsqu'il faut y jeter un oeil!

dans ta déclaration, tu inclu cette colonne (LF) pour ne pas avoir de décalage lors de la lecture, un exemple:

Code :

1
2
3
4
5
6
7
8
9
10
CREATE TABLE STAT_CAB_EXTERNAL
EXTERNAL FILE 'C:\FOO\foo.txt'
(
  ID                Char( 9),
  CAB               Char(12),
  NumWeek           Char( 4),
  FirstDateWeek     Char(10),
  LastDateWeek      Char(10),
  QS_PRO            Char( 2)
)

dans cet exemple, la colonne "QS_PRO" correspond au retour ligne suivi du saut de ligne (fichier windows par exemple)

j'utilise journellement ce procédé pour injecter des données via un automate et cela fonctionne très bien, il faut juste prendre soin de détruire la table externe pour permettre la mise à jour du fichier externe (plus sûr)

pour cela, l'idéal et un petit script sql qui exécute les commandes les unes à la suite des autres: création de la table externe, injection dans la table interne et destruction de la table externe.

je sais, c'est assez lourd, mais les performances sont étonnantes, en fait, je n'est jamais rien trouvé de plus rapide et efficace!

ne pas oublier que tu peux aussi construire une procédure stockée via le script sql pour régler les problèmes de liaisons (jointures) et la distributions/injections des données.

sinon, comme barbibulle le dit, il y a une foule d'utlitaires sur le net et des progs payants qui font cela très bien.

[djeant]

Merci... je ciomprend mieux le fonctionnement des tables externe.

Le pb c'est que je n'ai pas la main sur le format de fichier....
C'est un format du type :

Code :

1
2
3
4
5
6
7
 
NOMDETABLE1 03<COL1><COLONNNNNE2><XXXXXXX>....
NOMDETABLE2 03<COL1><COL2>....
.
.
.
NOMDETABLEN 03............................

Les différentes colones sont identifiées par leur position.

Quel est le séparateur de colonne pour les tables externes ?

[Barbibulle]

Il n'y a pas de séparateur, c'est un fichier à longueur d'enregistrement fixe.
Donc les colonnes sont de longueur fixe également.

[djeant]

Oui effectivement,
Enfin si on enléve le fait que j'ai plusieur table différente dans le même fichier.

[Barbibulle]

Je parlai des tables externes.

Votre exemple ne me permet pas de déterminer si c'est un fichier à longueur fixe. Mais à première vue je dirais que non. Et donc la solution des tables externes n'est pas envisageable à moins de traiter ce fichier avant.

[djeant]

Désolé je n'avais pas compris que tu parlais des tables externes...

Je pense que j'ai la solution.

Etant donné que le volume d'information n'est pas trés important qq centaines de lignes.

je vais faire un petit script en bash, pour mettre en forme les données.
J'aurais donc N fichiers plats avec des longueur d'enregistrement fixe.
Dans chacun des fichier je rajoute les CR/LF en fin de ligne.

Je pourrai ensuite charger mes données dans FB au moyen de N tables externes.

[jean-jacques varvenne]

pour rappel, le cr/lf en fin de ligne ne sert à rien lorsque le fichier est "connecté" à une table externe de firebird/interbase mais facilite la lecture en cas de doute.

donc si tu place un cr/lf en fin de ligne(enregistrement) pense à l'ajouter dans la description de la table externe, sans cela , tu aura à chaque enregistrement un décalage de 2 caractères...

mais tu t'en rendra compte assez vite...