Or you could use JDO and let the middleware handle the vendor specific
stuff (but it isn't mature enough IMHO), or encapsulate everything in
DAOs and use overloaded classes to handle vendor specific
implementations.
That's how we handled the MySQL / Firebird migration.

Rick DeBay

-----Original Message-----
From: Uno Engborg [mailto:uno@...]
Sent: Monday, December 20, 2004 11:42 AM
To: Firebird-Java@yahoogroups.com
Subject: Re: [Firebird-Java] setSelectableProcedure(true)


Roman Rokytskyy wrote:

>>So, is there any way to get a multirow ResultSet from a non
>>selectable procedure?
>>
>>
>
>No. You can make non-selectable procedure selectable by including a

SUSPEND;

>command at the end of procedure body.
>
>

I suspected that. This means that multiple rows from a CallableStatement

can't be achieved using standard JDBC API.
Or am I still missing something?

The reason I asked, is that I'm writing an application that is supposed
to work using various database engines on the
back end side.

As stored procedures triggers etc varies a lot from one database vendor
to the other, I won't have much choice but writing separate
SQL/procedure stuff for each database engine, that much is clear. But I

was hoping to be able to keep the java code unchanged regardless of
database back end. After all, that is the purpose of the JDBC
abstraction layer. If that doesn't
work we end up in a PHP-like situation where each database was handled
in a way of its own.

That's why I was suggesting that this behavior should be controlled by
some property accessed from standard JDBC API
e.g. as a property set when making the connection or when setting up a
DataSource connection factory. E.g. it could be hooked on to the
database url as a property. That way it would be possible for Firebird
returning multiple rows without using nonstandard JDBC calls and still
be backward compatible.

As you say, setting such selectable property to true, would mean that
calls to non selectable procedures would return empty
ResultSets. But couldn't that be fixed by a wrapping them in a
selectable procedure. Or people could use two connections
with different selectability settings. This is not good solutions but,
it would probably be better than the current state where you have to
write non JDBC code to get this behavior. It also makes it hard for web
designers using tools like dreamweaver
to get working pages from FireBird stored procedures.


Regards
Uno Engborg


[Non-text portions of this message have been removed]





Yahoo! Groups Links