At 01:10 PM 16/11/2010, Peter Faulks wrote:

>Win32 / C++ Builder
>
>Single thread.
>
>I've tried it and it seemed to work OK, but I have added more code and
>now have a weird bug.
>
>All the SQL is reading only, simple populating of list views and other
>windows controls. Nothing fancy.
>
>An SQL statement that works fine the first time around returns no rows
>after a call to another function that runs a different SQL statement.

Different instances of your statement class, of course...?

>The input sqlvar values are correctly set.
>
>If I comment out the call to the 2nd function the 1st SQL statement runs
>repeatedly (with different input params) with no problems.
>
>Each statement runs in a transaction block, I've tried running the whole
>shebang in one transaction - I know it's not the right thing to do

Why not? You can run many different statements in a single transaction.

>was just testing to see if it made a difference - it didn't.
>
>I've tried both DSQL_drop and DSQL_close with isc_dsql_free_statement(),
>no apparent difference. From what I can agglomerate from the docs I
>should be using drop - close is only for named cursors? and I don't need
>a named cursor just to read?
>
>I can't believe the error is from re-using the same XSQLDA structure
>repeatedly - though I 'spose that's the next thing I should try.

One statement, one XSQLDA. Two statements, two of 'em...etc. Once a statement is prepared, you can run it many times with different values in the input parameters.

>If only gpre wasn't such an abomination I'd use Embedded SQL.

gpre is an artifact. These days it's just used in the builds of the Firebird binaries and client tools. Embedded SQL hasn't been maintained.

>If I can't get this thing to work, I'm going back to Sybase SQLAnywhere.

Why not grab the IBPP sources from www.ibpp.org? IBPP has C++ wrappers for the whole of the API. Even if you have to reinvent the wheel to some degree for C++ Builder's idosyncrasies, surely it would knock out a lot of unnecessary sweat and tears....

./heLen