Annonce
L'appel à participation est ouvert jusqu'au 19 janvier 2025!
#1 Thu 20 July 2006 17:50
Lien Oracle / Access
Bonjour
Une question pas vraiment spatiale mais qui concerne des données spatiales sous Oracle ;o)
J'établis un lien ODBC entre une base sous Access 2000 et une table issue d'Oracle10g. Le champ ID de la table Oracle est un NUMAUTO. Une fois lié dans Access, ce champ est transformé en un champ TEXTE taille 38.
J'ai testé le pilote ODBC microsoft pour Oracle ainsi que le pilote Oracle, dans les deux cas le bug se reproduit.
Quelqu'un a t il une solution?
Merci
Cordialement
Y. Ardouin
Hors ligne
#2 Thu 20 July 2006 20:49
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4794
Re: Lien Oracle / Access
Bonsoir
J'ai peur de ne pas bien comprendre ta question ...
C'est quoi pour toi un champ de type NUMAUTO dans ORACLE ?
Ce type de champ est à mon avis une spécifité de ACCESS
ou bien parles tu d'une séquence dans Oracle ?
GeoBye, Pat
Dernière modification par pat (Thu 20 July 2006 20:50)
(Autodesk Expert Elite Team)
Hors ligne
#3 Fri 21 July 2006 10:18
Re: Lien Oracle / Access
Le champ en question est effectivement sous Oracle un number qui s'appuie sur une séquence. (ce qui "équivaut" a du numauto dans Access)
Y.A
Dernière modification par Yannick Ardouin (Fri 21 July 2006 10:18)
Hors ligne
#4 Fri 21 July 2006 17:59
- PierreF
- Juste Inscrit !
- Lieu: MARSEILLE
- Date d'inscription: 21 Jul 2006
- Messages: 6
Re: Lien Oracle / Access
Access essaye de mapper au mieux un type de colonne Oracle sur ses types propres. Dans votre cas, certainement un NUMBER(38) qu'il a mappé en TEXT(38) car le type numérique d'Access a une précision maximum de 28 chiffres.
En conclusion :
Oracle NUMBER(1 à 28) => Access Numeric(1 à 28)
Oracle NUMBER(> 28) => Access Text(x)
Quand vous regardez votre base Oracle à travers Geomedia, les types de données sont ceux de GDO (Intergraph). Geomedia lui aussi réalise un mappage des types Oracle en type GDO mais s'appuie sur ses métadonnées quand elles existent. Ici un NUMBER(38) avec une séquence attachée => LONG "NUMAUTO"
Bon WE
Pierre FLANDIN
Hors ligne
#5 Fri 21 July 2006 18:44
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4794
Re: Lien Oracle / Access
Hello
Donc on peut imaginer que en changeant la longueur du NUMBER dans Oracle
on peut espérer voir Access lui donner le type "Entier Long".
Je conseillerais NUMBER(8) ou NUMBER (9) au maximum,
si bien sur cela est possible ... Confère le MAX du champ dans Oracle.
GeoBye, Pat
(Autodesk Expert Elite Team)
Hors ligne
#6 Mon 24 July 2006 12:07
- PierreF
- Juste Inscrit !
- Lieu: MARSEILLE
- Date d'inscription: 21 Jul 2006
- Messages: 6
Re: Lien Oracle / Access
> Donc on peut imaginer que en changeant la longueur du NUMBER dans Oracle
> on peut espérer voir Access lui donner le type "Entier Long".
- Avec les anciens Access (97 ou plus vieux), oui
- Depuis, Microsoft à introduit le type "Numérique Décimal" équivalent du numeric Oracle mais avec une précision de 28 chiffres au lieu de 38 pour Oracle. Access convertit maintenant systèmatiquement les number(X) (où X<=28) en Décimal(X). Si X >28, cela devient du texte.
A l'utilisation, pas de différence entre Décimal(9) et entier long.
Hors ligne
#7 Wed 26 July 2006 12:32
Re: Lien Oracle / Access
Bonjour
Voici la solution que nous avons adoptée :
Sachant que le champ en question coté Oracle est déjà renseigné, il nous a semblé compliqué de chercher à restreindre la taille sur une séquence.
Nous avons donc créé une vue en utilisant la fonction Oracle TO_NUMBER qui nous a transformé la chaîne en nombre. Nous établissons le lien sur cette vue à partir d'Access, où nous récupérons un champ de type Numérique > réel double.
L'objectif est atteint
Merci pour vos réponses
Y. Ardouin
Hors ligne
#8 Wed 26 July 2006 14:42
- Patrice
- JeSuisCharlie
- Date d'inscription: 16 Sep 2005
- Messages: 4794
Re: Lien Oracle / Access
Coucou
Attention quand même aux champs de type REEL et plus spécialement à la précision en terme de nombre de décimales, il peut y avoir quelque surprises ...
GeoBye, Pat "prudent"
(Autodesk Expert Elite Team)
Hors ligne
