Discussion :

[Old_Chap]

Bonjour

La version 7.3 de DIVALTO est basée sur SQL (MS SQLserver).
Des procédures d'importations par excel existent dans le logiciel mais certaines sont assez lourdes et d'autres manquent.
Quelqu'un aurait il une expérience d'importation de données directement en SQL dans une base DIVALTO ? sachant qu'il y a évidemment des règles de cohérence à suivre...

merci

Cdlt.

[castorameur]

Re bonjour Old_Chap,

comme vous le savez je n'ai aucune expérience Divalto mais je connais SQL server.
La première chose à vérifier c'est si DIVALTO rajoute une information (une clé unique par exemple) entre la table SQL et la table utilisable dans DIVALTO.
La deuxième chose c'est l'évolution (split, ajout de champ...) des tables qui doit être documentée.

Ensuite vous pouvez utiliser l'outil SSIS avec SQL server à condition d'avoir une licence Visual Studio, il est très facile d'utilisation car une fois la connexion ODBC réalisée sur votre ancienne BDD il suffit de faire des clics de souris pour créer le flux d'import dans votre nouvelle bdd. Bien sur il y a d'autres ETL mais je n'ai pas eu l'occasion de m'en servir.

D'ailleurs comment sont réalisés les procédures actuelles DIVALTO ? Ce n'est quand même pas des macros Excel ?

Cdt
Castorameur

[Old_Chap]

merci de votre réponse.

Actuellement, la base de données de DIVALTO ne présente pas de contraintes, ni de trigger.
donc les contrôles de cohérence se font dans le code du logiciel lui même.
les importations de données par Excel se font par lien direct OLE vers le tableau Excel ouvert avec contrôle de cohérence et rapport en cas d'erreur.
c'est bien fait mais assez lourd.
DIVALTO ne communique pas sur un import direct dans la base SQL.

cdlt.

S

[castorameur]

[QUOTE]Actuellement, la base de données de DIVALTO ne présente pas de contraintes, ni de trigger./QUOTE]
Je vous rassure ce n'est jamais le cas quelques soit les erp, ce qui permet de facilement passer d'un serveur de bdd à un autre sans problème.
La logique métier et les contraintes sont toujours développé dans des outils propre à l'ERP.

Sinon une fois la feuille Excel ouverte, vous lancez un traitement dans DIVALTO qui réalise l'import et le contrôle, c'est cela ?

En fait un import direct dans la base sans contrôle peut faire planter l'ERP à l'ouverture d'un écran.
Mais si vous réalisez vos controles avant d'ouvrir l'ERP en prod, c'est une démarche envisageable.

cdt
s.

[Ebsilon]

Nouvelle sur le forum, je poste quand même une réponse, avec un temps de retard, certes...

Avec l'arrivée de SQL Server, l'idée d'attaquer directement la base Divalto en SQL est extrêmement tentante, néanmoins, cette technique est à éviter au maximum.
Les programmes Divalto d'import de données (qui s'appuient sur Excel notamment) permettent de garantir:

• l'intégrité fonctionnelle de la base, via une batterie de contrôles sur les données chargées
• l'intégrité technique, notamment vis-à-vis des clés étrangères qui ne sont pas implémentées sous forme de contraintes dans la base de données
• la performance de la base: la base de l'ERP contient un certain nombre de colonnes additionnelles techniques remplies par les traitement d'import et nécessaires pour des performances optimales

En bref, sur une table purement spécifique pourquoi pas faire un peu de SQL, pour le reste, c'est à éviter, voire à proscrire totalement pour le cas du moteur de pièces commerciales.

Dans tous les cas, rien n'est figé au niveau des programmes de chargement de données: on peut les surcharger, pour ajouter de nouveaux contrôles notamment, ou en créer de nouveaux.

Voilà, j'espère que ça répond à votre question...

[Old_Chap]

Nouvelle sur le forum, je poste quand même une réponse, avec un temps de retard, certes...

Avec l'arrivée de SQL Server, l'idée d'attaquer directement la base Divalto en SQL est extrêmement tentante, néanmoins, cette technique est à éviter au maximum.
Les programmes Divalto d'import de données (qui s'appuient sur Excel notamment) permettent de garantir:

• l'intégrité fonctionnelle de la base, via une batterie de contrôles sur les données chargées
• l'intégrité technique, notamment vis-à-vis des clés étrangères qui ne sont pas implémentées sous forme de contraintes dans la base de données
• la performance de la base: la base de l'ERP contient un certain nombre de colonnes additionnelles techniques remplies par les traitement d'import et nécessaires pour des performances optimales

En bref, sur une table purement spécifique pourquoi pas faire un peu de SQL, pour le reste, c'est à éviter, voire à proscrire totalement pour le cas du moteur de pièces commerciales.

Dans tous les cas, rien n'est figé au niveau des programmes de chargement de données: on peut les surcharger, pour ajouter de nouveaux contrôles notamment, ou en créer de nouveaux.

Voilà, j'espère que ça répond à votre question...

Bonjour

Merci pour votre réponse.
Je comprends bien les risques d'importer directement dans les tables en SQL.
Néanmoins, les outils proposés par DIVALTO ne sont pas complets.
Par exemple, je n'ai pas trouvé de quoi importer dans les "affaires" dans DIVALTO.
Or j'aurais besoin de reprendre des données du logiciel actuel pour les importer dans cette table Affaires (PRJAP) , qui est une table importante.
D'autres modules (DAV) proposent des outils d'importation de pièces, mais pas le module CRM.
Ce n'est pas très homogène.

D'autre part, l"écosystème" DIVALTO me parait très fermé : pas de forum, pas ou peu d'échange entre intégrateur, pas de communication de DIVALTO vers les clients finaux... A l'heure de l'open source, c'est assez décevant.

Cdlt