PS.: That goes for the AT clause on the GET DESCRIPTOR statement too. The connection name is not included in the
ECPGget_desc()call.
----- "Leif Jensen" <leif@crysberg.dk> wrote:
> Hello Bosco,
>
> Thank you for your comment. Yes, it would be nice to get some more
> comments on the allocate/deallocate on a connection issue.
>
> 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() function when 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 though it 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.