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@xxxxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
