G'day Helen

Thanks for your reply.

On Tue, 2010-11-16 at 16:30 +1300, Helen Borrie wrote:
> 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...?

statement handle? - is freed and allocated between SQL statements, yes.
As I said, I tried both DSQL_drop and DSQL_close...


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

Yes, but I was talking about having a single transaction for the life of
the app. That's a no no is it not?


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

So does the api does something strange to the XSQLDA? That might explain
the weird error?


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

I've looked at ibpp and tried it.. There's the hassle of having to
constantly convert strings from std::string to Unicode strings and it
seems to me that it's almost as much code to write as using the api
directly anyway.


I'll try the alloc/dealloc XSQLDA route. (Though it does seem strange to
me that this could be the cause)


Cheers


> ./heLen
>
>
>