Depuis Access, créer un enregistrement Oracle et connaître la clef

Salut,

as-tu essayé de saisir ta requête en SQL dans un objet requête de type SQL
Direct (menu Requête/Spécifique SQL/SQL direct)?

Thomas


"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de news:
uzGf$PetIHA.3680@TK2MSFTNGP05.phx.gbl...
Bonjour tout le monde,

Je cherche à savoir quelle est la meilleure solution, en développant un
frontal Ms-Access 2003 pour une base Oracle 8.1.7.0, pour créer un
nouvel enregistrement dans une table avec une clef primaire GUID, et
connaître en retour la valeur de la clef ?

J'ai essayé de générer le GUID sous Access et de le passer sous forme de
chaîne de caractères dans la requête INSERT INTO avec le GUID parmi les
champs renseignés, mais je me ramasse une erreur ORA-00911 (soit
-2147217900 pour Access), caractère non valide, sur

UPDATE TABTEST SET CLEF='{95401BD8-9103-4AFC-AC59-CF3247769106}' WHERE
SURNOM = 'Minette';

alors que dans SQL*Plus la réponse est "1 ligne mise à jour".

(j'ai eu la même erreur lors du INSERT INTO, le UPDATE est juste plus
facile à répéter pour rédiger la question).

Si je remplace les apostrophes autour du GUID par des guillemets,
j'obtiens, même sous SQL*Plus, l'erreur ORA-00972, l'identificateur est
trop long.
Lorsque j'ai fait une recherche là-dessus je suis tombé sur des
considérations fumeuses, du style les noms de tables et noms de champs
sont limités à trente caractères. Je cherche à introduire un GUID dans
un champ, pas à renommer le champ pour l'appeler comme ce que je cherche
à mettre dedans. Sommes-nous bien d'accord sur le fait que le nom de
champ "CLEF" ne comporte que quatre caractères, et que la longueur d'un
GUID est imposée ?

Il y aurait bien la solution d'ouvrir un objet Database pour y ouvrir un
Recordset, mais je n'ai réussi à faire ça qu'en lecture seule, donc pour
créer un enregistrement, pour le moment c'était fausse piste. (J'envoie
mes requêtes SQL sur un objet Connection.)

J'ai réessayé ma requête SQL ci-dessus en enlevant les accolades, en
remettant les apostrophes, en enlevant les traits d'union ...

La base Oracle pourrait certes générer un GUID automatiquement lors de
la création d'un enregistrement, mais la difficulté est alors de
connaître sa valeur depuis Access, si on considère qu'on ne créerait pas
de champ clef si les valeurs des autres champs étaient suffisantes pour
désigner l'enregistrement visé. Passer par l'heure de création,
peut-être ? Moui, si je ne trouve pas autre chose, d'autant qu'on
travaille en multi-utilisateurs ...

Pour le moment mon champ clef est de type CHAR(40).
Je sais qu'on peut aussi essayer RAW(16) -ah tiens, ça ne fait pas la
moitié de 40, ça ...- mais j'obtiens les mêmes erreurs en envoyant un
GUID vers un champ de ce type depuis Access.

Je n'ai probablement pas épuisé toutes les combinaisons, mais si
quelqu'un pouvait me guider vers quelque chose de probant, j'apprécierais.

J'ai essayé de générer le GUID sous Access et de le passer sous forme
de chaîne de caractères dans la requête INSERT INTO avec le GUID pa rmi

les champs renseignés, mais je me ramasse une erreur ORA-00911 (soit
-2147217900 pour Access), caractère non valide, sur

UPDATE TABTEST SET CLEF='{95401BD8-9103-4AFC-AC59-CF3247769106}'
WHERE SURNOM = 'Minette';

Bjr,

Comme disait Coluche, "Je vous le donne Emile !" ...

Le caractère invalide, c'est le point-virgule !

Si je relance la même requête sans y inclure le point-virgule de
terminaison, ça passe comme une lettre à la poste (enfin ... celle
d'avant l'OMC). Je n'ai plus qu'à vérifier avec un DLookup derrière que
ça a bien été enregistré, et l'affaire est réglée.

Eh bien comme on dit, la nuit porte conseil ...

Si je mets des guillemets l'identificateur reste trop long, enfin bon on
ne met pas de guillemets autour d'un GUID et puis c'est tout.


*

(J'ai essayé ce que dit Thomm, mais sans réelle surprise, m'a été dit
que je devais faire appel à une requête accessible en écriture.)

En fait, je n'ai pas encore tout terminé pour ce qui est d'écrire une
chaîne de caractères.
De cette manière, je peux insérer un "e dans l'a" directement dans la
requête INSERT INTO, en tapant le caractère 230 au pavé numérique dans
la requête INSERT INTO, donc jusque là rien à redire.
En revanche, pour le e dans l'o, qui ne fait pas partie de la même
partie de la table, il y a plus de boulot. Je veux dire, pour
l'utilisateur ce sera pareil, mais le code ne pourra pas passer
directement le champ dans la requête.

Si je l'insère de cette manière, il n'est pas reconnu.
Si je l'insère par la fonction CHR() d'Oracle, pas de problème il est
inséré (pas lisible depuis SQL*Plus, mais lisible depuis Access, ce q ui
est l'essentiel), mais alors ça veut dire qu'il faut détecter dans la
chaîne à insérer tous les caractères devant faire l'objet de ce g enre de
précaution, et puis les insérer avec quelque chose comme

UPDATE TABTEST SET SURNOM=CONCAT('C', CONCAT(CHR(156), 'ur')) WHERE
NOM='Minette'

Il faut être motivé ;)

D'autant que j'ai repéré le e dans l'o, mais certainement d'autres
caractères, encore, doivent faire l'objet de cette cuisine.
Et ci-dessus j'ai donné un exemple en dur, mais il faudra que je déte cte
la position de chaque caractère à traiter, et générer automatique ment
une requête résultante capable de transférer la chaîne.

Si j'ai un peu de chance, quelqu'un a déjà eu à mitonner ça ...
Je pense au temps que ça pourrait me faire gagner ... vertigineux :)

(ou alors peut-être y a-t-il une solution moins besogneuse, ça aurait
même l'avantage de plus d'élégance, peut-être.)

Oh mais je réalise ... une fois qu'on manipule des fonctions CONCAT et
CHR on entre plus dans le domaine d'Oracle, d'autant que dans SQL*Plus
la syntaxe est la même.
Allez, je vais aller recopier ça où il faut. Enfin si les anciens de la
discipline lisent ici ...

En tout cas merci à tous ceux qui ont pris le temps de lire, et à Tho mm
qui a même fait plus.