Access 2002 en liaison avec base oracle

[Kobras]

Bon j'ai un problème au boulot
Je conçoit un moulinette de données en vue d'un passage à SAP (gros progiciel pour ceux qui connaissent pas)
Ma moulinette est en Access 2002 (la boite avais pas tellement d'autres outils) et la base ou je vais chercher les données est en Oracle (8.1 apparemment).
Pour y accéder, je lie les table dont j'ai besoin via ODBC avec le driver d'Oracle.
Le problème est que des fois j'ai des messages d'erreur en accédant aux données (que ce soit à la main en ouvrant la table ou par mon code VBA.
Ce message d'erreur est le suivant :

La précision du champ décimal est trop petite pour accepter la valeur que vous avez essayé d'ajouter.

En cherchant, sur Google je suis tombé sur des messages faisant état de bug dans le driver ODBC qui provoquerai une mauvais reconnaissance du type de donnée des champs des tables Oracle.
La solution étant de choisir le driver de Microsoft pour Oracle et d'ajouter un paramètre dans le code d'attachement de la table mais je vois rien pour le modifier (on le vois effectivement quand on laisse sa souris 2 sec sur la table dans Access mais rien pour y modifier)
Si je modifie juste le driver ODBC par celui de Microsoft, j'ai alors une autre erreur lors de le l'execution de mon code.

bref est-ce que quelqu'un a déjà rencontré ce problème et/ou a une solution à me proposer ?

Merci.

[Catw]

Pour modifier les paramètres des connexions ODBC :

Panneau de configuration -> Outils d'administration -> Sources de données (ODBC), tu choisis le driver et tu cliques sur "Configurer".

Si tu ne vois pas le driver dans la liste, tu cliques sur "Ajouter..." et tu ajoutes le driver.

Je pense que j'ai bon au niveau des noms (plus l'habitude des versions anglaises, moi);

J'espère que ça répond à ta question... De toutes façons, SAP, c'est le mal.

[ChemicalStöf]

c'est le mal, mais ça rapporte!

[Kobras]

Bon déjà, j'aimerais bien savoir en quoi SAP est le mal, simple curiosité.
Mais bon de toute façon je bosse pas sur SAP, je m'occupe juste d'extraire des donnée des systèmes actuels (sous Oracle donc) que je traite et refournit sous forme de fichiers Excel. Ces fichiers Excels seront alors utilisé par d'autres personne pour alimenter SAP.

Enfin bref.
Pour mon problème, j'essaye d'appliquer la solution décrite en fin de cette page :

http://forum.hardware.fr/hfr/Programmation/SGBD-SQL/access-conflit-access-sujet_50796_1.htm

qui dis :

OK Voila la solution:
-> utilisation du driver M$ uniquement
-> dans le code d'attachement, ajouter:
MaTable.Attributes = dbAttachSavePWD
-> enregistrer, c'est bon !

Pour l'utilisation du driver MS, pas de pb.
Par contre pour le code d'attachement je vois pas.

Dans l'administrateur de source ODBC, j'ai bien ajouté une nouvelle connexion au serveur via le driver MS. Si je fait configurer dessus, j'ai :
- Nom de la source de données : Je met un nom pour définir ma source de données ODBC
- Description : j'ai laissé à vide
- Nom d'utilisateur : j'ai mis le login de la base Oracle
- Serveur : j'ai mis le nom du serveur.
Un bouton Option me permet d'afficher d'autres options :
- Traduction avec un bouton sélectionner
- Performance avec la taille de la mémoire tampon (qui est de 65535), 2 case à cocher
- 3 cases à cocher de personnalisation.

Bref, je vois pas trop ou mettre le code d'attachement "MaTable.Attributes = dbAttachSavePWD"

Et si je lance ma requête à la main dans Access avec l'utilisation des table lié via le driver MS, ca marche, mais si je lance ma procédure automatique avec le formulaire et le code VBA attaché, j'ai cette erreur :

Aucune valeur donnée pour un ou plusieurs des paramètres requis

sur ma ligne :

rst_source.Open SQL, CurrentProject.Connection, adOpenForwardOnly, adLockReadOnly

[Kobras]

Bon, au cas ou quelqu'un tombe sur ce post en ayant le même problème.
Donc j'ai pas réussit à résoudre le bug donc au final je fait une super requête que j'exécute avec un outil externe (Toad dans mon cas mais il doit en avoir d'autre du même genre) et j'exporte le résultat sous forme de fichier texte avec séparateur point virgule. J'importe alors ce fichier dans une table Access que je peut triter comme bon me semble.

Donc j'ai pas réussit à résoudre le bug mais j'ai pus le contourner.
Inconvénient : on a pas un accès en temp réel et faut refaire un extract à chaque fosi qu'on veux des données à jour
Avantage : je peut faire des left join avec condition fixe (genre table.champ = mavaleur) alors que sous Access 2002 on peut pas, faut metre les comparaison avec valeur dans le where ce qui flingue le fait de faire une jointure facultative (le left du join). Autre avantage, le traitement (SQL sur Toad plus VBA sur Access est bien plus rapide qu'avec la requête avec les tables lié sous Access)

[Catw]

Désolé de pas avoir répondu plus tôt... C'est pas dans le code VBA qu'il faut mettre la ligne que tu donnes ? Genre tu crées le lien en VBA pis tu mets ta ligne ?

Sinon, SAP c'est le mal parce que l'interface est mal foutue, parce qu'il faut être certifié si on veut faire quoi que ce soit dans le système (donc payer un consultant qui coute la peau des fesses), et que ça tourne quand même super lentement pour de l'Oracle (une base Oracle + frontend en php marche vachement mieux que ça. Ou un frontend dans n'importe quel langage, d'ailleurs).

Enfin, le système SAP est trop généraliste pour s'appliquer à des cas particuliers.

Mais ça coute moins cher que de développer une solution en interne...

[ChemicalStöf]

euuuuuuh pas d'accord sur pas mal de points là pour le coup
1) pas besoin d'être certifié pour toucher au système; je ne sais pas d'où tu sors ça.
2) SAP contient tout ce qu'il faut, dans plusieurs domaines fonctionnels distincts: logistique, finance, ressources humaines, relations clients/fournisseurs...
3) Ca tourne tout à fait correctement, pour peu que les indexs sont utilisés correctement (comme n'importe quelle D. D'ailleurs SAP n'est pas marié avec Oracle: on peut connecter plusieurs types de DB différentes, même si c'est vrai que c'est Oracle dans 95% de cas.

Mais c'est vrai que l'interface est ultra mal branlée: elle date de l'époque du Cobol et a peu évolué depuis. D'un point de vue configuration, c'est pas du tout user friendly. Et d'un point de vue dev, l'ABAP est un langage assez simple et plutôt bien adapté au système.