Problema com STRING gigante no PreparedStatement

E ai rapaziada!

Seguinte, estou utilizando o PreparedStatement para executar um INSERT.

Se eu uso o método setString(int parameterIndex, String x) dá zica, pq minha STRING é muito grande.

Resolvi utilizar o setUnicodeStream(int parameterIndex, InputStream x, int length) que é Deprecated mas resolveu meu problema no ORACLE.

Quando fui testar no SQLServer, deu zica… Disse que o DRIVER do SQL não implementa esse método setUnicodeStream.

Resumindo, preciso saber como posso setar minha STRING no PreparedStatement sem ter problemas com drivers e etc.

Alguém manja?

Abçs

Rodrigo

Voce pode colocar um livro inteiro em uma String, desde que tenha memoria. O teu problema nao eh com a coluna do banco nao?

Rafael

Não…!

Meu banco funciona normal usando HIBERNATE, só que preciso utilizar JDBC nesse caso!

Meu problema é exatamente esse: http://java.sun.com/j2se/1.5.0/docs/api/java/sql/PreparedStatement.html#setString(int,%20java.lang.String)

Alguém sabe outro método?

Abçs

Se o teu problema no Oracle é com Strings gigantescas e campos VARCHAR2 limitados a X caracteres, veja se trocar essas coisas por CLOB resolve.

Inté.

Então… Ignorem o BANCO, independente de ORACLE, SQL SERVER, POSTGRE ou qualquer outro a aplicação hoje funciona utilizando persistência (HIBERNATE), logo, não há problemas com o banco, tamanho do campo ou até mesmo com tipo do campo.

O problema é que hoje eu preciso fazer a GRAVAÇÃO com JDBC e o método setString no ORACLE me retorna que a STRING é muito grande. (problemas na implementação do DRIVER)

Quando resolvi o problema no ORACLE utilizando o setUnicodeStream vi que o driver do SQL não implementa esse método, porém, o setString no SQL dá certo pq a implementação com certeza é mto diferente do driver do ORACLE.

Minha dúvida é; Alguém sabe um método, ou já utilizou algum que funcione utilizando um tamanho ABSURDo de String em qualquer um desses bancos com qualquer um desses drivers!?

Abç~s

[quote=silvars]Então… Ignorem o BANCO, independente de ORACLE, SQL SERVER, POSTGRE ou qualquer outro a aplicação hoje funciona utilizando persistência (HIBERNATE), logo, não há problemas com o banco, tamanho do campo ou até mesmo com tipo do campo.

O problema é que hoje eu preciso fazer a GRAVAÇÃO com JDBC e o método setString no ORACLE me retorna que a STRING é muito grande. (problemas na implementação do DRIVER)

Quando resolvi o problema no ORACLE utilizando o setUnicodeStream vi que o driver do SQL não implementa esse método, porém, o setString no SQL dá certo pq a implementação com certeza é mto diferente do driver do ORACLE.

Minha dúvida é; Alguém sabe um método, ou já utilizou algum que funcione utilizando um tamanho ABSURDo de String em qualquer um desses bancos com qualquer um desses drivers!?

Abç~s[/quote]

Ok, ok, independente de qual banco você está utilizando, no seu lugar eu iria trocar essa coluna aí que você tenta manipular via “setString” por uma coluna do tipo CLOB e passaria a manipulá-la via “setClob”, se o caso for de ser necessário usar Strings de tamanho absurdo.

Inté.

Sim KWill

Tentarei usando CLOB ou BLOB, o tipo do meu campo é: LONG e rola legal…

Não preciso que seja CLOB cara…

Estranho é que usando o HIBERNATE ele rola, já estou tentando achar no DRIVER do Hibernate o que ele faz com esse tipo, mas não estou achando!

Abçs

[quote=silvars]Sim KWill

Tentarei usando CLOB ou BLOB, o tipo do meu campo é: LONG e rola legal…

Não preciso que seja CLOB cara…

Estranho é que usando o HIBERNATE ele rola, já estou tentando achar no DRIVER do Hibernate o que ele faz com esse tipo, mas não estou achando!

Abçs[/quote]

Se for o LONG que é “Character data of variable length (A bigger version the VARCHAR2 datatype)”, pode ser que “setCharacterStream” possa ser usado no lugar do “setUnicodeStream”. E o método “setCharacterStream” não está marcado como “deprecated” (tendo como referência o javadoc da especificação 1.5 do Java).

Inté.

Justamente meu caro Kwill!

Acabei de usa-lo (statement.setCharacterStream), e funcionou…

Acredito que os DRIVERS dos diversos BDs implementem esse método…

Mas obrigado pela ajuda meu caro!

Abçs

Rodrigo