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 <[EMAIL PROTECTED]>) 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
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
