On Fri, Apr 04, 2003 at 04:31:46PM +0200, Paul Reeves wrote:

>
> [detailed explanation of problem snipped]
>
> As you seem to be getting on so well (doing private builds of Fb 1.0,
> OdbcJdbc driver etc)

Thanks,..

> I'd recommend taking a look at gpre to use as a
> debugging tool.
> [snip]
> The idea I'm suggesting is basically to see if you can reproduce the
> problem with a gpre based program.

Ah. I was hoping not to have to write a test case, mind you gpre
has made it easier...

Anyway back to the plot. I've got a working test case , which
as close as possible duplicates the sqlda layout used by the
the odbc drivers (plus a bug fix[1] I've already sent to the
odbc-dev list) . And the test case exhibts the bug.

Even better I've narrowed it down to a specifc behaviour in the
sqlda layout for null fields.

To prepare the sqlda my program does the following:-

while (myalloc_sqlda(&sqlda)) {
EXEC SQL DESCRIBE INPUT q USING SQL DESCRIPTOR sqlda;
}

myprepare_sqlda(sqlda,record,upd_fields);
send_data(sqlda,record,upd_fields);

myalloc_sqlda() does the sqln,sqld field comparision and reallocs
the sqlda if necessary.
myprepare_sqlda() set the sqldata and sqlind pointer to the approriate
places in record. (upd_fields gives order fiels in the
query).

send_data() is where the 'bug' is. This function adjust the sqlda
to be like the odbc driver generates and encodes date fields.

It contains the followings code stanza:-
int nullmode= sqlda->sqlvar[i].sqltype & 1;
int type = sqlda->sqlvar[i].sqltype-nullmode;
/* Date processing code goes here */
if ( *(sqlda->sqlvar[i].sqlind)== -1) {
sqlda->sqlvar[i].sqltype=SQL_LONG+1;
/* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*/
/* This line is the one of interest [1] */
} else {
sqlda->sqlvar[i].sqltype=type;
sqlda->sqlvar[i].sqlind= NULL;
}

This stanza is supposed to simulate the NULL support in the Odbc
drivers I have (both the fb one and the easysoft one work this way),
in that NULLs are always set to the engine as NULLed SQL_LONGs no
matter what the base type of the field is, additional the low bit
which is use to indicate wheter NULL are allow is only set on
NULLed fields. Additionally sqlind is always NULL on non null fields.

Anyway its the first part of this which has the problem if I don't
reset the sqltype field on NULLed data then the update succedds.

One final wriggle is the error message is not very explantory , if
not plan wrong - the error mesasage I'm getting is:-
'validation error for column ENQDATE, value "*** null ***" '
which wouldn't be surprising except for this field isn't null in either
the existing data in the table or the new data in the sqlda.

Anyone have any ideas whats going on? surely I can't be the only
one hit by this.

[1] The bug fix to the odbc diver I did does affect this
line which causes the problem. In the original odbc driver
sqltype would have been set to SQL_LONG not SQL_LONG+1[2]
[2] Yes , I did try backing this out, its not the problem.
--
Roger. Home| http://www.sandman.uklinux.net/
Master of Peng Shui. (Ancient oriental art of Penguin Arranging)
GPG Key FPR: CFF1 F383 F854 4E6A 918D 5CFF A90D E73B 88DE 0B3E
Work|Independent Systems Consultant | http://www.firstdatabase.co.uk/
--
Roger. Home| http://www.sandman.uklinux.net/
Master of Peng Shui. (Ancient oriental art of Penguin Arranging)
GPG Key FPR: CFF1 F383 F854 4E6A 918D 5CFF A90D E73B 88DE 0B3E
Work|Independent Systems Consultant | http://www.firstdatabase.co.uk/


[Non-text portions of this message have been removed]