ID: 11969
Updated by: sniper
Reported By: shinelight@excite.com
Old Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Windws 98
PHP Version: 4.0.6
New Comment:
What if you change the include()'s to include_once() ?
--Jani
Previous Comments:
------------------------------------------------------------------------
[2001-07-09 06:13:37] shinelight@excite.com
Hello, I have once again found another bug...you guys couldn't possibly remove them all, could
you? :)
Anyway, my problem is a very interesting one (this will take a while to read - so bear with
me)...took me a while and lots of testing to verify that PHP v4.0.6 has a *MAJOR* problem with the
ODBC engine when using include's (relative/absolute - doesn't matter). The short story is
that there is no problem if you only include() one file. However, in my case, I've got
includes 5-7 levels deep with file I/O and what-not...but no database calls except in the top-level
routine. Here is the SQL code I was running against a database (trimmed down a bit):
include("$DBDir/initdb.php");
$sql = "SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID
FROM ProdTitle";
$sql_result = odbc_exec($db, $sql);
odbc_fetch_row($sql_result);
...
$sql = "INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X,
ProdScreens_X)
VALUES ($Max_ProdTitle_ID, '$ProdTitle_X', '$ProdDesc_X',
'$ProdLogo_X', '$ProdScreens_X')";
echo "$sql<br><br>";
$sql_result = odbc_exec($db, $sql);
...
include("$DBDir/enddb.php");
initdb.php and enddb.php perform normal odbc_connect and odbc_close operations. This portion of the
code works fine. However, when I add the following line:
include("index.php");
PHP now does something extremely bizarre. index.php contains the following data:
<?
include("../index.php");
?>
PHP parses the includes and displays everything correctly on the page, however, when I check the
database 1 extra row has been added, I have verified that PHP is re-executing the starting script,
but it refuses to display anything from the 'echo "$sql<br><br>";'
line of code. Even more bizarre is that if I add, say, a SELECT statement and execute it but
don't retrieve any results, PHP re-executes the starting script 3 times (thus 3 extra rows in
the database). If there were a loopback in the script, PHP would run forever (I turned off the
time-limit). If it was some scripting error, the 'echo
"$sql<br><br>";' result would have shown up in the response page. So,
PHP is restarting the script on its own and destroying data integrity. Here is a snippet of a SQL
capture that verifies what I've been talking about:
First the SELECT statement...
fffc020f-fffae443 ENTER SQLExecDirect
HSTMT 00D7076C
UCHAR * 0x00797670 [ -3] "SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ a
FROM ProdTitle\ 0"
SDWORD -3
fffc020f-fffae443 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS)
HSTMT 00D7076C
UCHAR * 0x00797670 [ -3] "SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ a
FROM ProdTitle\ 0"
SDWORD -3
Now the INSERT statement - Note the values being inserted!!!
fffc020f-fffae443 ENTER SQLExecDirect
HSTMT 00D70C00
UCHAR * 0x0079AA60 [ -3] "INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X,
ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (5, 'asdf',
'asdf', ' ', ' ')\ 0"
SDWORD -3
fffc020f-fffae443 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS)
HSTMT 00D70C00
UCHAR * 0x0079AA60 [ -3] "INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X,
ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (5, 'asdf',
'asdf', ' ', ' ')\ 0"
SDWORD -3
So far so good. At this point the log file shows that the connection is being dropped and even the
environment handle is destroyed. Then, all of a sudden, the connection is re-instated and two more
queries are processed:
First the SELECT statement (basically the same as before)...
fffb7f03-fffb93db ENTER SQLExecDirect
HSTMT 00D7076C
UCHAR * 0x00796A90 [ -3] "SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ a
FROM ProdTitle\ 0"
SDWORD -3
fffb7f03-fffb93db EXIT SQLExecDirect with return code 0 (SQL_SUCCESS)
HSTMT 00D7076C
UCHAR * 0x00796A90 [ -3] "SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ a
FROM ProdTitle\ 0"
SDWORD -3
Next, the INSERT statement - this one is *VERY* different...
fffb7f03-fffb93db ENTER SQLExecDirect
HSTMT 00D70C00
UCHAR * 0x00799DC0 [ -3] "INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X,
ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (6, ' ', ' ',
' ', ' ')\ 0"
SDWORD -3
fffb7f03-fffb93db EXIT SQLExecDirect with return code 0 (SQL_SUCCESS)
HSTMT 00D70C00
UCHAR * 0x00799DC0 [ -3] "INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X,
ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (6, ' ', ' ',
' ', ' ')\ 0"
SDWORD -3
At this point I can safely say that my PHP application did *NOT* willingly take part in what
happened with that last query since that would require my variables to be completely wiped out of
existence. Even then, I would have been able to tell that the script was the culprit because of the
'echo' statement in the correct place.
I think my temporary solution to the problem will be to use the header() function and spit a
Location: back to the browser. I don't like the concept, but I don't think there is any
other way at this point.
Pertinent System Information:
OS: Win98
CPU: Dual Intel PIII 500 mHz
RAM: 384MB RAM
HD: 18GB HD
Web Server: Xitami v2.4d9
PHP: PHP v4.0.6
ODBC: MDAC 2.6 Service Pack 1, Microsoft Jet Drivers v4.0 - Serivce Pack 3, Access 97 Test Database
MacTruck
------------------------------------------------------------------------
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11969&edit=1