Discussion :

[philouZ]

Bonjour,

J'accède à une base en ODBC et lorsque je fais un select, le nombre de décimale du réel est limité à 10. Or j'ai encore au moins un chiffre derrière. En effet, ce réel est la transformation d'une date/heure en réel. Là où je n'ai pas de chance, c'est que ce réel est utilisé comme clé unique dans la table. Donc si je n'arrive pas à récupérer l'intégralité des décimales, je ne peux pas mettre à jour les données dans la table.

Lorsque je lance la même requête sur DBeaver, j'arrive à tout récupérer en modifiant le nombre de décimales affichées. Ça doit donc être possible.

Quelqu'un sait-il comment faire pour modifier la précision dans une connexion odbc ?

Je tiens à préciser que je ne peux pas modifier la clé, et que ce n'est pas moi qui ai fait une telle débilité, malheureusement maintenant faut que je fasse avec.

Merci à tous par avance

[tbc92]

J'ai peur que ODBC soit bloquant à ce niveau là.
Mais tu peux contourner (je sais, c'est très moche) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

select trunc(id/1000,0) as nbre_milliers , mod(id, 1000) as nb_unites from ma_table

[philouZ]

J'avais pas pensé à multiplier le tout par X. Merci je teste ça demain

[philouZ]

Bon du coup j'ai tout multiplié par 10¹⁵ et là je peux tout récupérer. J'ai plus qu'à tout rediviser par 10¹⁵ dans le code pour retrouver cette clé.

Quelle galère...

Merci tcb92 pour m'avoir mis sur la voie.

[tbc92]

Il y a peut-être une solution plus propre (mais je doute). C'est une piste que je proposais en dernier recours.

[philouZ]

Bon je me suis enflammé. Je récupère la majeure partie des lignes mais pour un certains nombre la manip ne fonctionne pas étant donné que les réels manquent de précision, la multiplication me modifie tout de même le dernier chiffre significatif ce qui est gênant.

Je n'ai pas encore trouvé de solution.

[Lo²]

Bonjour,

Même en utilisant des monétaires à la place des réels ?

[tbc92]

Je pense qu'il faut que tu découpes la valeur en 2 : les bits de poids fort / les bits de poids faible ; ou tu multiplies par 10^8, et tu récupères la partie entière d'une part et la partie décimale d'autre part.
A priori, ODBC a une limite max pour la précision d'un nombre (hypothèse : 12 chiffres significatifs) , et même avec la multiplication par 10^15, on a toujours besoin d'autant de chiffres significatifs.
En coupant en 2 , on a maintenant 2 champs, et chacun a moins de 12 chiffres significatifs.

[philouZ]

Je me suis rendu compte qu'en multipliant par X, le réel continue à afficher des données qui ne sont pas les bonnes. J'ai trouvé une autre solution en rajoutant une colonne ID auto dans la table qui n'est pas la mienne mais ça n'empêche personne de fonctionner à priori. De cette manière j'ai plus de problème d'identifiant unique.

Merci à tous...