From: [EMAIL PROTECTED]
Operating system: Windws 98
PHP version: 4.0.6
PHP Bug Type: Scripting Engine problem
Bug description: PHP repeats ODBC queries when using include()...
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
--
Edit bug report at: http://bugs.php.net/?id=11969&edit=1
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
