FreeTDS Development Group

["Anton van Straaten" <anton AT appsolutions.com>]

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.

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."

Anton