Subject | Re: [firebird-support] Using the API |
---|---|
Author | Peter Faulks |
Post date | 2010-11-16T00:10:07Z |
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.
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, I
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.
If only gpre wasn't such an abomination I'd use Embedded SQL.
If I can't get this thing to work, I'm going back to Sybase SQLAnywhere.
Regards
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.
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, I
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.
If only gpre wasn't such an abomination I'd use Embedded SQL.
If I can't get this thing to work, I'm going back to Sybase SQLAnywhere.
Regards
On Mon, 2010-11-15 at 09:51 +0100, masotti wrote:
> Hi,
>
> On 13/11/2010 06:25, ozjazzfan wrote:
>
> > If I'm writing an app that only generates SQL that has up to a known max
> > number of params (say up to 10 in and 60 out), why can't I just allocate
> > the max at the beginning of the app and re-use the structures over the
> > lifetime of the app?
> >
> > Set the sqld and sqln members to the number of params actually used,
> > assign the sqlvar array and away you go...
>
> not a C++ guru here, so... ;)
> anyway, as a first step, I'd say that you must serialize and synchronize
> requests (i.e. no multithreading and no asynch).
> You don't specify dev. sys. and O.S. so I've not many other things to say.
>
> Ciao.
> Mimmo.
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>