I would like to offer my recent experience in the hope that it will help
others avoid the wasted effort and frustration I managed to burden myself
with yesterday.  I will start by stating that the conclusions I have drawn
may seem obvious at first blush, however in a troubleshooting environment it
is sometimes difficult to see the forest for the trees.  This is
particularly true when several principles of PHP syntax are working in
concert to produce a problem.

My problems started when I found myself in the rare position of needing to
write a function that accessed global variables rather than passed values or
references.  This need arose because I was writing a data access abstraction
function and would have no way of knowing in advance what variables would
need to be accessed or in what order.  The total number of possible
variables was large when compared with the total number of lines of code in
the function.  If I had chosen to write the function to accept an
associative array that could be extracted within the function to produce the
needed variables the total number of lines of code needed outside of the
function to produce the array would have been greater than the total number
of lines of code within the function.

Because the purpose of choosing to use a function rather than writing the
code several times was to reduce the number of lines of code and provide
clarity to the script I decided that passing an array to the function was
not an option.

I decided to simply write the function so that it had access to all
variables in the GLOBALS array to overcome this problem.  The function was
as follows:

// Function to send query and retrieve result pointer
function GetData($Query)
{
extract  ($GLOBALS);
$Result = mysql_query($Query, $db_conn)
       or die (mysql_error());
Return $Result;
}

The function accepts an SQL statement as an argument and returns a pointer
to a result set.  The SQL statement that is passed to the function is one of
many defined constants, many of which contain variables.  For example:

define ("ClassesByTeacher","SELECT Classes.SectionNo, Period, CourseNo,
Title, Teacher FROM Classes, Attendance WHERE Classes.SectionNo =
Attendance.SectionNo AND Teacher LIKE \"$Teach\" AND Attendance.Date =
\"$SQLDate\" GROUP BY Classes.SectionNo");

This particular statement needs to have access to the $Teach and $SQLDate
variables.  When these variables were passed as GET values in the URL the
function worked as expected.  However, if I assigned the variables within
the code of the script outside the function I invariably received empty
result sets.  I spent quite a bit of time under the impression that the
global variables where not being accessed by the function unless they where
GET variables.  This did not turn out to be the case.  Upon adding debug
code to the script I was able to determine that the function was correctly
accessing the global variables, but the mysql_query function was not.  As it
turned out, and this is the part that may seem obvious, the problem resulted
from the fact that the define statement was evaluating the variables to ""
before they were actually set in code.

The result was an SQL statemente like this:

SELECT Classes.SectionNo, Period, CourseNo, Title, Teacher FROM Classes,
Attendance WHERE Classes.SectionNo = Attendance.SectionNo AND Teacher LIKE
"" AND Attendance.Date = "" GROUP BY Classes.SectionNo

which explains the empty data sets and lack of an error message.

The define statements are in a seperate file that is included into the
script.  It is my general practice to include all files that contain
functions as the beginning of a script and this is what I had done here.  As
soon as the file containing the defines was included the variables were
evaluated to empty strings within the defined constant before the variables
were set to usable values within the code.  Moving the include statement
below the variable assignments in the script provided the solution.

The lesson I learned is this:

When including files that contain declare statements which in turn contain
variables, always include the file after the variables have actually been
set to their desired values.

Fred




-- 
PHP General 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]

Reply via email to