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