[JDBC]Problème avec PreparedStatement

Version imprimable

J'ai un petit problème avec un PreparedStatement:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
//Je crée ma requête
String req_dest = ReqCrea.get_req(trait);
//Je l'affiche
System.out.println("Voila " + req_dest);
//La passe au PreparedStatement
PreparedStatement requete_dest = connection_bis.prepareStatement(req_dest);
//Boucle sur les champs 
for (int i = 1; i < array_size+1; i++) {
	System.out.print("~ " +i+"  "+rs.getObject(i)+" ~");
	requete_dest.setObject(i,rs.getObject(i));
	System.out.println("~ " +i+" ~");
}

Et voila ce que j'obtiens....
Je ne comprends pas pourquoi j'ai ce message d'erreur....

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Voila insert into Cogi_StructRestit (Id_bonsai,Code_bonsai,Lib_bonsai,Responsable,Level_bonsai,Info_bonsai) values (?,?,?,?,?,?)
~ 1  298 ~~ 1 ~
~ 2  7580 ~~ 2 ~
~ 3  Cardiologie C ~~ 3 ~
~ 4  Professeur BAUTERS ~~ 4 ~
~ 5  SERVICE ~~ 5 ~
~ 6  null ~java.sql.SQLException: Type de colonne non valide
        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)
        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:211)
        at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:274)
        at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:2084)
        at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:2198)
        at DataPvd.execute_traitement(DataPvd.java:223)
        at Main.main(Main.java:9)

Si quelqu'un a une idée, je suis preneur!
Merci d'avance a tous.

08/07/2005, 11h40
thibaut

La colonne 6 est de quel type ?
08/07/2005, 11h44
tomca

Bah c'est du Varchar2 en fait, comme les autres champs...
Au départ j'ai cru que l'erreur était du au null (la colonne 6 retourne un null), donc j'ai mis en place un test si null au lieu de setObject, je fesais setNull....mais ca marche pas mieux...le problème ne doit pas être ca...
08/07/2005, 12h16
Samanta

et qd tu exécutes la requête directement sur ta base de données, est-ce que ça marche?
08/07/2005, 12h51
tomca

Ben le truc c'est que pour le moment j'essaie même pas de l'éxecuter...donc au niveau Java il ne peux pas savoir si la requête est bonne ou pas...l'erreur apparait vraiment à la création et l'initialisation du PreparedStatement....
Je sais vraiment pas pourquoi il ne veux pas me prendre mon dernier paramètre...
08/07/2005, 12h55
adiGuba

Salut,

Sur quelle ligne est l'erreur ???

a++
08/07/2005, 12h55
rootel77

le code pour setNull?
08/07/2005, 12h56
thibaut

Sinon envoie un peu plus de code stp :wink:
08/07/2005, 13h02
tomca
l'erreur est levé sur la ligne:

Code:

requete_dest.setObject(i,rs.getObject(i));

Pour le code en cas de null j'avais mis:

Code:

requete_dest.setNull(i, java.sql.Types.NULL);

Mais ca marche pas...
Je suis pas sur que java.sql.Types.NULL est le bon second paramètre (je pense qu'il faut donner le type du champ, seulement c'est une appli entièrement dynamique...et je connais pas le type des champs quand je travail dessus...c'est juste une recopie...)

Pour tester, j'ai essayer ca:
Au lieu de faire :

Code:

requete_dest.setObject(i,rs.getObject(i));

J'ai fais :
Code:

1 2 3 if(rs.getObject(i)!=null){ requete_dest.setObject(i,rs.getObject(i)); }
Et ca ca a l'air de fonctionner....du moins j'ai pas d'erreur...
Mais je trouve ca bizarre...un Object peut être null, pourquoi la méthode setObject ne veux pas le prendre?

Merci de votre aide!

:tagcode:
08/07/2005, 13h13
rootel77

effectivement l'ereur vient du type passé comme paramètre, si tu ne peux pas connaitre le type de colonne dynamiquement. ta solution reste le meilleur choix, car affecter un NULL à une colonne equivaut à ne pas l'affecter du tout.
08/07/2005, 13h20
tomca

Effectivement c'est ce que je me dis aussi...
Mais il me reste toujours un question pour laquelle je trouve pas de reponse...
La méthode setObject prend en paramètre un Object, et un Object peux être null....pourquoi la méthode refuse t'elle alors un paramètre null? Pourquoi JDBC ne gère pas ce problème?
Si quelqu'un a une réponse, je le remercie d'avance...parce que la je pige pas...
Merci également a tous ceux qui m'ont aidé à avancer!
08/07/2005, 13h25
adiGuba
Ok je vois mieux le problème...

setObject() n'accepte pas de null parce qu'il se base sur le type de l'objet Java pour le changer en un type SQL compatible...
Or un null n'est pas typé donc impossible de faire cette conversion.
De plus il y a plusieurs valeurs différentes de null en SQL selon le type de la colonne (par exemple, TIME et TIMESTAMP n'ont pas les mêmes 'valeurs nulles' que VARCHAR...)

Donc tu es bien obligé d'utiliser setNull() avec le type exact de ta colonne...

Citation:

Envoyé par tomca

(je pense qu'il faut donner le type du champ, seulement c'est une appli entièrement dynamique...et je connais pas le type des champs quand je travail dessus...c'est juste une recopie...)

Si j'ai bien compris, ton ResultSet rs contient les éléments que tu dois ajouter dans la requete ?
Donc tu peux connaitre le type de la colonne du ResultSet via son MetaData (qui devrait correspondre à celui de la table dans laquelle tu fais l'insertion, non?).

Avec le code suivant ca devrait aller :
Code:

1 2 3 4 5 ResultSetMetaData metadata = rs.getgetMetaData(); for (int i = 1; i < array_size+1; i++) { requete_dest.setObject(i, rs.getObject(i), metadata.getColumnType(i)); }
La méthode setObject(int,Object,int) devrait gérer les valeurs null puisqu'on lui passe le type SQL...
Si ce n'est pas le cas il faudra le faire en manuel avec un if()...

a++
08/07/2005, 13h31
tomca

Merci beaucoup pour ton analyse...je comprends beaucoup mieux le problème maintenant...
J'avais pensé au META Données pour obtenir le type de la colonne...
Mais pour les besoins de mon applications, je dois parfois mettre en place un transcodage entre le type de donnée source, et le type de donnée destination...donc le type que je trouve dans le ResultSet n'est pas forcement le même que celui du PreparedStatement...
En fait, par exemple je peux avoir du varchar dans la base source, mais dans la base de destination, il se peux très bien que ce soit du "Number" qui est attendu.

Pour l'instant je continue a utiliser le if manuel, bien que je ne trouve pas ca très élégant...
En fait, ce qu'il faudrait, c'est que je récupère les méta données de la base de destination...mais ca je sais pas si c'est possible....
08/07/2005, 13h39
adiGuba

Citation:

Envoyé par tomca

Mais pour les besoins de mon applications, je dois parfois mettre en place un transcodage entre le type de donnée source, et le type de donnée destination...donc le type que je trouve dans le ResultSet n'est pas forcement le même que celui du PreparedStatement...
En fait, par exemple je peux avoir du varchar dans la base source, mais dans la base de destination, il se peux très bien que ce soit du "Number" qui est attendu.

Là c'est sûr que tu devra le gérer toi même... et je ne vois pas ce qu'il y a d'inélégant à utiliser un if ;)

Citation:

Envoyé par tomca

En fait, ce qu'il faudrait, c'est que je récupère les méta données de la base de destination...mais ca je sais pas si c'est possible....

Tu dois pouvoir faire cela avec le MetaData de ta connection :
http://javasearch.developpez.com/j2s...#getMetaData()

Sinon une solution serait de faire un select * sur la table d'insertion pour lire ses metadata...

a++
08/07/2005, 13h44
tomca

Merci encore pour votre aide...
Je vais tenter l'utilisation des méta données de la table de destination...
J'avais aussi pensé au select...mais bon, ca fais des requêtes en plus...(et au vu de l'appli, qui est censé a terme remplir un data warehouse...je dois faire attention a pas trop allourdir les accès BD..)
enfin je vais tester tout ca, et au pire, c'est vrai que le if n'est pas si laid que ca :lol:
08/07/2005, 13h59
tomca

En y regardans a deux fois, le if ca marche pas très bien...
En effet, j'obtiens une belle erreur Oracle:

Citation:

ORA-01008: not all variables bound

Qui en gros veux dire...eh oh, tu m'a pas donné tous mes paramètres...bon, bah je suis bon a me mettre dans les méta données de la base de destination....