Hello Bosco,
Thank you for your comment. Yes, it would be nice to get some more comments on the allocate/deallocate on a
connectionissue.
I have verified that in my case deallocating a prepared statement, it guesses the wrong connection and returns an
error.(The right one is doing auto-deallocation at disconnect time, though).
However, I just noticed that allocating a descriptor with the "AT <connection>" clause,
EXEC SQL AT :_thisDbConn ALLOCATE DESCRIPTOR :descname;
generates an ECPGallocate_desc() call without any connection name and that this can "screw up" the ECPGget_desc()
functionwhen guessing a connection. I could of course use:
EXEC SQL SET CONNECTION <connection name>;
before the allocate, but that would need mutex's all over to make sure that other threads will not set the connection
too.
Any idea why the ecpg pre-compiler doesn't use the named connection for the ALLOCATE DESCRIPTOR statement even
thoughit allows it ?
Please help,
Leif
----- "Bosco Rama" <postgres@boscorama.com> wrote:
> Leif Jensen wrote:
> >
> > Is it really not possible to use 2 separate connection within 1
> thread
> > at the same time ? or is it an error in the ecpg library ?
>
> It should be entirely possible to run multiple connections in a
> single
> thread as long as you manage the 'AT connName' clauses properly.
>
> Though, IIRC, using an 'AT connName' clause on any sort of
> 'deallocate'
> statement generates an error in ecpg:
>
> ecpg -o test.c test.pgc
> test.pgc:35: ERROR: AT option not allowed in DEALLOCATE statement
>
> This happens when trying to deallocate a query or a prepared
> statement.
> I don't use descriptors but the error message indicates it's _any_
> sort
> of deallocate.
>
> So, it would appear that you can allocate on a connection but not
> deallocate from one. :-(
>
> I'm wonder if Tom or Michael can shine some light on this one?
>
> Bosco.
