Re: SQLSTATE not updated in ecpg program. - Mailing list pgsql-interfaces

On Thursday 28 December 2006 10:42, ken jennings wrote:
> > From: Michael Meskes
> > On Thu, Dec 28, 2006 at 08:07:09AM -0500, Ken Jennings wrote:
...
> Yes, It was originally written for 8.1.5 and ran perfectly fine there on
> all our systems. The output.txt file in the tarfile shows a couple runs
> when built/run for 8.2.0. It appears sqlca.sqlstate is either not being
> updated or is stomped on by something.
>
> > sqlstate[0] =0
> > sqlstate[1] =8
> > sqlstate[2] =0
> > sqlstate[3] =0
> > sqlstate[4] =1
> >
> > Using the 8.1 libs I seem to get a memory overrun:
> >
> > ./testpgc test1234 postgres
> > ...
> > sqlstate[0] =1
> > sqlstate[1] =2
> > sqlstate[2] =3
> > sqlstate[3] =4
> >
> > Yes, if I use test12 as db name sqlstate[2] and sqlstate[3] are empty.
>
> The program uses command line arguments for the database
> connection information.  argv[1] is the dbname string and and argv[2] is
> the user or user/password string. db_connect( argv[1], argv[2] ); So, there
> shouldn't be a scope problem.  Argv[] strings should stay where they are in
> memory and not change for the duration of the program.
>
> int db_connect( char * dbname, char * username )   just copies the pointers
> provided (from argv) to host variable names that ecpg will know: EXEC SQL
> BEGIN DECLARE SECTION ;
>         char * target = dbname;
>         char * user   = username;
>     EXEC SQL END DECLARE SECTION ;
>
> and then uses them:
>     EXEC SQL CONNECT TO :target USER :user ;
>
> The target and user host variables themselves will lose scope when the
> function ends, but the actual values are still the pointers from argv which
> won't change.  Is it necessary that the host variables used in the CONNECT
> TO be static for the duration of the program?

I've tried every alteration I can think of to the host variables in the 
DECLARE SECTION and in every case sqlca is being stomped on by something. The 
data overwriting sqlca appears to be a copy of (part of) the target/dbname 
value.  (Or more generally, some of the data in the ECPG* parameters.)

Things I've tried:

Changed the declarations of target and user to const per the online docs.
Declared them static.  
Moved the DECLARE SECTION outside the db_connect() function, making them 
global.  
Moved them outside the function and made them static.
Performed strdup() of the function arguments and assigned the new strings to 
target and user.
Declared target and user as actual char arrays and copied the contents of the 
dbname/username to them.
I looked at the C output of ecpg and replaced the EXEC SQL for the CONNECT 
with the same C code:     { ECPGconnect(__LINE__, 0, target , user , NULL , 
NULL, 0); }.  Still doesn't work.
I replaced target and user with literal strings in the function call above and 
in the EXEC SQL CONNECT version and it still doesn't work.
I added the "AS" clause to the CONNECTION thinking maybe the library was 
confused about something if a parameter is null, and it still doesn't work.

sqlca is being partially overwritten during EXEC SQL calls.  It's beginning to 
look like ecpg is broken in some environments.  Or there's something that 
should have been done differently during .configure .

This problem happens with 8.2.0 installed on our Athlon systems:
Linux wolverine 2.6.13-15.12-default #1 Thu Aug 24 11:23:58 UTC 2006 i686 
athlon i386 GNU/Linux
Linux cerebro 2.6.13-15.12-smp #1 SMP Thu Aug 24 11:23:58 UTC 2006 i686 athlon 
i386 GNU/Linux
We found this problem does not occur when the program is built and run on a 
system using an actual Pentium 4:
Linux nawm 2.6.13-15.12-default #1 Thu Aug 24 11:23:58 UTC 2006 i686 i686 i386 
GNU/Linux