This was a problem originally submitted on msql-mysql-modules:

Under Darwin 1.3.3/PPC G4, using mysql built from mysql-3.23.36+, the perl
module DBD-mysql-2.0901 (and previous versions of DBD::mysql do this as well)
returns 0 for $dbh->{'mysql_insertid'} (return LAST_INSERT_ID from a database
handle), but returns a correct value for $sth->{'mysql_insertid'} (return
LAST_INSERT_ID from a statement handle).

The same module compiles and operates correctly under Linux/i686, which is the
only environment I have to test against.

I am not a C programmer, but from what I can tell by looking at the C code in
the module (written by Jochen Wiedmann <jo...@ispsoft.de>) the calls which fail
seem to refer to functions defined in the mysql.h file in the mysql source tree.
JW suggested I post this problem to this list to see if anyone can shed any
light on the problem.

Not knowing enough C to be able to find the source of the problem, the best hint
I can provide as to what's going on is something to do with the size of some of
the data structures. I say this because compiling the module also produces the
error:

dbdimp.c: In function `mysql_db_reconnect': dbdimp.c:1694: warning: assignment from incompatible pointer type

while all definitions of the pointer type declared at this point in the code are
a SV object, no exceptions that I can find, and JW's code calls the built-in
mysql functions directly via two structures, one of which is very clearly
defined, being the statement handle structure, and also the structure
associated with the working function, not the broken one.

The only plausible (to me) explanation I can come up with (and I repeat, I am
NOT BY ANY MEANS a C programmer or a chip guru) is that the data type/size for
some of the standard definitions may be strange on the G4 because of the Altivec
functions built into the chip. Perhaps the datatype is not being properly
measured, and the 0 results from some bit-offset incompatibility. Or, possibly,
I'm just blowing out my a$$.

In particular, the last_insert_id datatype in the perl module is set at
"my_ulonglong" which has variable definitions under different architectures. I
see that the configure script uses a measurement of what size a typedef longlong
is on the resident architecture, but my attempts at trying to compile with and
without the conditional definition of the longlong datatype only produce
compiler errors in DBD::mysql (because I don't know what I'm doing! I'm
probably just defining a longlong as a long in some places and not others, like
between general.h and mysql.h).

I hope someone else out there has a better idea of the source of the problem,
because I'm just about to give up and rewrite a lot of perl code which depends
on the $dbh->{'mysql_insertid'} call, and I REALLY don't want to do that.

Regards,

BK