FreeTDS Development Group

["Schörk, Andreas" <andreas.schoerk AT infor.de>]

> -----Original Message-----
> From: Anton van Straaten [mailto:anton AT appsolutions.com]
> Sent: Samstag, 15. September 2001 05:02
> To: TDS Development Group
> Subject: [freetds] Re: JDBC-Gurus, please comment
> 
> 
> Andreas Schörk wrote:
> > My big question is, what should executeQuery do:
> > should it search for the first ResultSet or fail,
> > if the first statement is a not result generating statement ??
> 
> I'm not a JDBC guru, but if it helps, I can tell you the 
> behavior of other
> JDBC MSSQL drivers with my spTestExec query.  I have not yet 
> run the new
> test code that you have provided, but I will try that with these other
> drivers over the weekend.
> 
> I ran my own tests previously with three other JDBC drivers: JTurbo,
> Sprinta, and JSQLConnect.  All three drivers succeed in 
> invoking spTestExec,
> whether execute() or executeQuery() is used.  In all cases, 
> from the point
> of view of the Java client, there is no sign of an 
> intermediate resultset -
> the only resultset that the driver returns to the client is 
> the final, valid
> resultset.
what do you mean by intermediate resultset ??
moreResults() always returns true until nothing more exists, so all the 
updateCount generated by the changing and not changing statements are
ignored 
or do the return only one ResultSet all the time even if there where more ?
How do such drivers handle procedures which contain changes. What about the 
getUpdateCount in this case ? Does execute return false ??
> 
> If I'm understanding this correctly, whatever intermediate 
> packets appear in
> the protocol stream, as a result of a statement like 
> INSERT...EXECUTE, are
> simply being ignored by these other JDBC drivers, and the first valid
> resultset is returned to the JDBC client.
> 
> BTW, I tried the last hack you suggested, adding in:
> 
>         if (tds.isResultSet())
>          {
>             result = true;
>               break;
>          } else
> 
> ...but I'm not sure if I added it in the correct place.  It 
> eliminated the
> protocol confusion errors, but ordinary queries no longer 
> worked.  I began
> getting messages like "java.sql.SQLException: Stored 
> procedure '#jdbc#1' not
> found."
> 
I did some additional fixes already checked in, which should solve the
problem. But the driver is not ready yet to be released to customers.
Especially my changes concerning the fixing one TDS-Stream on one connection
might have some unpredictable results. Also the changed caching of
Procedures
on TDS-Streams.
On the other side I am very much interested in your experiences.
Andreas