Discussion :

[cedy-kassy]

Bonjour, je ne sais pas si c'est le bon endroit pour poster mon problème, mais voila, j'ai créé une appli dont les données de la base venaient d'un fichier excel. A ce moment-là j'ai réalisé l'import du fichier dans une table via SSMS, ensuite j'ai alimenté ma base en respectant les contraintes par du code. Enfin, la table créée au début fut supprimée.
A présent, pour les besoins de mise à jour massive, je voudrais intégrer dans mon appli une fonction d'import, qui serait transparente pour les utilisateurs (ils n'auraient pas à rentrer dans SSMS pour le faire).
Le but du jeu c'est que lorsque l'on choisit un fichier et que l'on clique sur "importer":
1-->Une table est créée en base avec les mêmes noms de colonne et les mêmes données (naturellement!!) que le fichier excel,
-->les données sont "acheminées" vers les différentes tables
-->On n'ajoute que les données qui ne sont pas encore présentes
4--> La table temporaire est supprimée.

Est-ce que cela est réalisable? si oui, comment(pour le point 1 et 4 seulemnet)?
Merci,

[pulsdrum]

Bonjour,

L’ETL de Microsoft SSIS est fait pour cela.

Voici les différentes étapes :
• Créer un nouveau package SSIS
• Créer un nouveau paramètre contenant l’adresse de ton fichier Excel
• Créer une nouvelle source de donnée Excel avec comme Expressions « Property : ExcelFilePath » ton paramètre créé précédemment
• Créer les différentes étapes d’extraction/transformation/chargement
• Une fois ton package Builder, tu l’exécute dans ton application avec la commande Dtexec en lui passant comme paramètre le chemin de ton fichier Excel à charger.

++

[cedy-kassy]

Merci pour ta réponse pulsdrum . Cependant, ne l'ayant jamais fait, j'ai du mal à "visualiser" les étapes. Aurais-tu un lien à me proposer pour que je m'y mette tout de suite??

[pulsdrum]

En effet cela peut te paraitre un peu barbare si tu ne connais pas encore SSIS

Un didacticiel est présent à cette adresse : ICI

[Pelote2012]

Perso j'ai mis 4 heure à comprendre comment injecter un fichier multi page dans ma base. Mais maintenant, il me faut moins de 10 minutes.

SSIS (SQL Server Integration Services)
est un outil d'intégration de données dasn une BDD.
Tu peux faire cela par fichier plat, xml, excel ... et plein d'autre option comme retravaillé la forme de tes données

Cela se fait par une interface graphique, c'est très conviviale et facile à comprendre le paramétrage

Tu crée une tache de flux de données, une connexion de fichier excel, une connexion à ta BDD.
Puis tu n'as plus qu'à mapper les colonne de ton excel sur la table souhaitée

Voilà dans les grandes lignes

[cedy-kassy]

Merci pour les réponses les gens,
@pulsdrum, paradoxalement j'ai déja utilisé SSIS sans véritablement m'en rendre compte (lors de l'import du fichier excel de base).
@Browny, quitte à y mettre 5h, je n'y vois aucun inconvénient tant que cela me permettra d'atteindre mon objectif. Et l'interface graphique dont tu parles, est-ce l'interface d'un package SSIS disponible par exemple sous Sql server 2008? dans ce cas, comment va-t-on l'appeler depuis mon appli?
Bref....je vais pas vous ennuyer plus longtemps avec des questions de non-initié, donc je fonce immédiatement en découdre avec cet ETL/SSIS "stuff".
Je reviens vers vous pour d'autres questions.

[Ptit_Dje]

Bonjour,

L’ETL de Microsoft SSIS est fait pour cela.

Voici les différentes étapes :
• Créer un nouveau package SSIS
• Créer un nouveau paramètre contenant l’adresse de ton fichier Excel
• Créer une nouvelle source de donnée Excel avec comme Expressions « Property : ExcelFilePath » ton paramètre créé précédemment
• Créer les différentes étapes d’extraction/transformation/chargement
• Une fois ton package Builder, tu l’exécute dans ton application avec la commande Dtexec en lui passant comme paramètre le chemin de ton fichier Excel à charger.

++

Ce n'est malheureusement pas toujours si simple.
En effet, il n'est pas dit que SSIS (ou plutot DTEXEC) soit au même endroit qu'ou tourne l'interface java et encore moins ou se trouve le fichier excel.
Un autre soucis est la localisation du fichier excel, souvent sur un poste client.
Donc dans une architecture n-tier, on imagine assez facilement l'utilisateur traiter son fichier excel sur son poste client, l'interface java sur un front-end (avec l'application server... ou pas, dans ce cas on rajoute un tier) et ensuite le serveur DB (avec segregation... ou pas du serveur SSIS).
Après reste les droits nécéssaires pour exécuter DTEXEC et aussi les droits d'insérer dans la DB.

Je rajouterai donc au minimum la copie du fichier excel vers un share accessible par le compte exécutant le package (on se détache du poste client).
Ensuite, il y aura aussi peut-être le besoin de creer un job executant le package SSIS avec différent credentials.

Bref, quelque chose qui parait simple en théorie mais qui peut vite devenir un casse-tête. L'intégration SQL Server/Excel étant à mon gout faible et ratée.

[pulsdrum]

Je pense que tu noircis un peu le tableau. Voici une configuration simple à mettre en place :

- Un répertoire partagé sur le serveur
- Ton programme Java permet à l'utilisateur de choisir un fichier Excel et l'envoi dans le répertoire partagé
- Un Job SQL scrute le répertoire partagé, lorsqu'un fichier Excel y est présent, le package SSIS l'intègre.

++

[Ptit_Dje]

Noircir le tableau, non, je parle de problématique réaliste rencontrée dans le milieu professionel.
Pourquoi je dis que la problématique de l'intégration entre les 2 technos n'est pas réussie ?
Car si tu considères le nombre de composants à mettre en place (et à maintenir (migration/DRP...)) nécéssaires pour un tâche qui devrait être si simple à priori, je trouve que cela fait beaucoup.
De plus il y a pas mal de soucis avec les drivers excel à utiliser avec SSIS qui nécéssitent l'exécution des packages en 32bit.
Concernant le job qui scrute le folder d'input, cela mène à de l'asynchrone ou avoir un process en boucle infinie sur le serveur.
Quid du multiuser ?

Je trouve qu'on est loin de l'idée end-user qui veut juste selectionner un fichier, appuyer sur un bouton et tout charger dans la DB directement.

[cedy-kassy]

wow wow wow!!! les copains... je suis pas encore un expert SQL Server(j'en suis qu'à la leçon 3 du didacticiel ) et je suis pas encore arrivé à dtExec, ni ne sait comment créer un job SQL(du moins pas au moment où j"écris). Merci pour le lien pulsdrum, je regarde ça vivement tout de suite.
Ptit_Dje, merci également d'émettre des réserves, t'as lu mon problème, selon toi, comment pourrais-je faire sans l'ETL? ou plutôt, comment t'arrives à contourner ces contraintes pour faire ce que je veux faire?
Si l'exécution du package se fait à partir d'un seul poste, en local, et la base de données modifiée est ensuite substituée à celle présente sur le serveur, est-ce que ça contribuerait à éclaircir le tableau??