Discussion :

[Jidefix]

Bonjour,
j'ai un petit souci qui est plus ou moins contourné mais j'aurai bien aimé le comprendre quand même:
J'ai une table Oracle avec 3 colonnes, un Blob, un Number et un Varchar (ça fait très blague belge comme début...)
Je fais donc le select des trois colonnes dans mon petit connecteur JDBC, et ensuite je récupère le résultat.

Code :

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

1
2
 
byte[] tableauDirect rs.getBytes(1);

me renvoie un tableau de taille 88, avec des données visiblement farfelues dedans
tandis que

Code :

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

1
2
3
 
Blob blob = rs.getBlob(1);
byte[] tableauBlob = blob.getBytes(1, (int) blob.length());

me renvoie le bon tableau, de 1800 octets environ, soit une différence assez énorme.

Je précise que le getBytes direct marchait avant et qu'on a fait quelques modifs de configuration que j'ai oublié, à la suite de quoi ça s'est mis à merdouiller.

Quelqu'un a-t-il déjà vu ça?

Quelques détails techniques:
- Base Oracle 10g
- connecteur ojdbc14.jar
- Voici le datasource:

Code xml :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
<local-tx-datasource>
        <jndi-name>jdbc/tn9</jndi-name>
        <use-java-context>true</use-java-context>
        <connection-url>jdbc:oracle:thin:@monserveur:1521:MABASE</connection-url>
        <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
        <user-name>login</user-name>
        <password>password</password>
        <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
        <min-pool-size>0</min-pool-size>
        <max-pool-size>20</max-pool-size>
        <blocking-timeout-millis>5000</blocking-timeout-millis>
        <idle-timeout-minutes>5</idle-timeout-minutes>
        <check-valid-connection-sql>select sysdate from dual</check-valid-connection-sql>
        <metadata>
                <type-mapping>Oracle9i</type-mapping>
        </metadata>
  </local-tx-datasource>

Comme je l'ai dit c'est pas très urgent la solution a été trouvée mais du coup je m'inquiète un peu pour la suite, parce que ça semble pas très stable comme système...

[NicoL__]

Bonjour,

Pour moi ces deux codes sont radicalement différents.
Dans le 1er cas la données est stockée dans un champ binaire qui est stocké dans un champs de type RAW.
Et le second un champs stocké dans un BLOB.
Peut-être que vous êtes passé d'un champ ROW à BLOB pour des raisons de taille de l'élément stocké en binaire.

[Jidefix]

Ah non la base n'a pas changé d'un iota, seule l'application a été modifiée, il a toujours s'agit d'une colonne BLOB, contenant un objet java sérialisé avec les pieds (je n'ai pas la main sur le format ou l'insertion soit dit en passant)...

[NicoL__]

Effectivement des 2 implémentations devraient fonctionner... du coup je ne vois pas, peut-être un changement de version de ojdbc14.jar...

[tchize_]

doc de getbyte()

Retrieves the value of the designated column in the current row of this ResultSet object as a byte array in the Java programming language. The bytes represent the raw values returned by the driver.

Autrement dit, rien ne te garantie que c'est le contenu de ton blob. Probablement que le driver te renvoie la référence vers les blob.

De mémoire oracle a deux manière de renvoyer au client les blob: inclu dans le stream, ou sous forme de référence à des streams à redemander au serveur. C'est le serveur qui choisi ce qu'il renvoi en fonction de divers critère. Je suppose que le serveur à décidé qu'à partir de maintenant, un blob de 1000 bytes, c'est via un stream séparé qu'il faut le récupérer.

[Jidefix]

OK, donc d'un point de vue fonctionnel, le getBytes est une très mauvaise idée dans la mesure où on ne peut pas garantir ce qu'on reçoit...
C'est noté, merci!

en même temps j'imagine que c'est pour ça qu'on a inventé le getBlob()...