RE: Executing a Stored Procedure returning rows from a Temporary table

[Priyesh Mashelkar <pr...@mastek.com>]

I buy your point.
But the method in which this occurs is executeQueryProcedure(). And the procedure is expected to return a result set. Correct me if I am wrong.
I am using the following settings:
   	        <property name="JDBC.Driver" value="com.microsoft.jdbc.sqlserver.SQLServerDriver"  />
   	        <property name="JDBC.ConnectionURL" 
   	        	value="jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=DBName" />
Do you know of any issues with this driver?


-----Original Message-----
From: Jeff Butler [mailto:jeffgbutler@gmail.com]
Sent: Monday, August 08, 2005 7:41 PM
To: user-java@ibatis.apache.org
Subject: Re: Executing a Stored Procedure returning rows from a
Temporary table


iBATIS is behaving according to the JDBC spec in this case. 
executeQuery cannot be a general solution because stored procedures
may not always return result sets.  So it seems to me that this could
be a driver problem, rather than an iBATIS problem.

Jeff Butler

On 8/8/05, Priyesh Mashelkar <pr...@mastek.com> wrote:
> Hi,
>        Havent received anybodies mail regarding this.
>        Tried digging through the iBATIS source code and found the following. The   "public void executeQueryProcedure(RequestScope request, Connection conn, String sql, Object[] parameters,  int skipResults, int maxResults, RowHandlerCallback callback)" method in SqlExecutor uses the following code to execute and get the ResultSet:
>        cs.execute();
>        rs = cs.getResultSet();
>        When data from a Temporary table is selected in the Stored Procedure, the Result Set "rs" is null.
>        But if we use the following code instead the result set returned is proper:
>        rs = cs.executeQuery();
> 
>        Will this change have any repercussions somewhere else? Kindly reply ASAP. Its urgent.
> Regards,
> Priyesh
>



MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from all computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Executing a Stored Procedure returning rows from a Temporary table

[Koka <22...@gmail.com>]

> I have a Stored Procedure which uses the input parameters passed to 
> it and returns rows from a temporary table which it creates

I'd avoid changing iBatis code. Instead I'd go for a workaround like
executing procedure that fills the table (but does not return rows)
and next (in the same transaction of course) just run ordinary select
statement on tha table. Just one extra statement sounds to me far
better than changing iBastis code

Koka

Re: Executing a Stored Procedure returning rows from a Temporary table

[Jeff Butler <je...@gmail.com>]

I see your point too...I think that in your case it could be a viable
solution to make this change and recompile the iBATIS source for your
own use.  Whether that change makes it into the official iBATIS source
is another question.  I believe the committers have generally shied
away from coding around buggy drivers.

I haven't worked with SQL Server for several years, so I don't know
about the quality of the MS drivers now - but they used to be
horrible.  I have used this product in the past with good success:

http://www.jnetdirect.com/products.php?op=jsqlconnect

It has a trial available - maybe you could try it to see if it is
indeed the driver.

Jeff Butler


On 8/8/05, Priyesh Mashelkar <pr...@mastek.com> wrote:
> I buy your point.
> But the method in which this occurs is executeQueryProcedure(). And the procedure is expected to return a result set. Correct me if I am wrong.
> I am using the following settings:
>                <property name="JDBC.Driver" value="com.microsoft.jdbc.sqlserver.SQLServerDriver"  />
>                <property name="JDBC.ConnectionURL"
>                        value="jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=DBName" />
> Do you know of any issues with this driver?
> 
>