ID: 11969
Updated by: sniper
Reported By: [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
--
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]
