I know I promised you that this wouldn't be your average "Resource id #2" error as most of the articles I have read throughout the web has been dealing with people who do not understand that you cannot directly access the results of a query from the resource link given them but that you have to use some sort of fetch function with it. My problem is different.
Before the sys admin changed the box to Gentoo and PHP 4.2.3, the script in question worked perfectly fine and normal. However, the other day, one of the guys brought up a complaint that the script was broken. After I tried it out and saw that it was as they said, I proceeded to figure out what the problem was.
In the script, I am using the session object to store information the user wants to enter into the database, but I hold onto it until all the information is collected and enter it in at once. However, some of the later queries were unable to access values stored in the session under a particular index.
I placed debug statements throughout the code to see what the problem was with the session object and found that instead of an array where I was trying to pull values from, I see "Resource id #2". So, I began checking my code to make sure nothing was rewriting to that space of the session object. After I saw nothing was, I was stumped.
It wasn't until last night when I was printing out the session object's contents at multiple points in the script that I found out that it wasn't until after I made the first connection to the database that the array in the session object that I wanted was changed to the "Resource id #2" value.
Now in looking at the two, the only link was that the local variable which was storing the connection to the database, $connection, and the index of the session object, $_SESSION["connection"], had nothing in common except their names. One was a local variable and the other was a session variable.
In a "what the hell, lets try something" mood, I changed the local variable's name from $connection to something like $DBconnection just so there wouldn't be any sort of connection between the two. Finally it began to work right, but why in the heck should that have mattered? It has been working for almost a year now without problems like this.
So here is the basic question (sorry for making you read through the whole thing but was absolutely necessary), how is the session object being affected by a database connection that is not being stored in the session and the only link between the two is that the name of the local variable is the same as an index in the session object.
Thanks in advance
