What error does it give? I still could do with knowing more about the under lying structure and sql that you are using. this kind of debugging is akin to fumbling around in the dark.
The @ (or error suppression symbol) is evil because it makes debugging your code an absolute nightmare. A better solution is to test the code that may create an error before hand, instead of just hiding the error. Also it may hide errors that are useful to the debug process, its all very well and good when its on live but when you are developing it you need errors to be displayed in order for you to be able to fix them, after all you can't fix what you don't know about. In short there are a number of ways to do it without the '@' evil.
Take this example:
PHP Code:
$pDbConnection = mysql_connect('localhost', 'root', '');
mysql_select_db('test');
$sSql = 'SELECT * FROM `categorides` c WHERE `c`.`cat_id`BETWEEN 1 and 3';
$pResult = mysql_query($sSql, $pDbConnection);
while($row = @mysql_fetch_array($pResult))
{
echo var_dump($row);
}
The sql is incorrect because there isnt a table 'categorides'
This will just hide the fact the query is incorrect and fail silently.
However if we take the @ off we get:
Code:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in
Here is the correct way to do it (or at least on of the ways):
PHP Code:
$pDbConnection = mysql_connect('localhost', 'root', '');
mysql_select_db('test');
$sSql = 'SELECT * FROM `categorides` c WHERE `c`.`cat_id` BETWEEN 1 and 3';
$pResult = mysql_query($sSql, $pDbConnection);
if(!$pResult)
{
die('Error in query: ' . mysql_error($pDbConnection));
}
while($row = mysql_fetch_array($pResult))
{
echo var_dump($row);
}
Now here we are anticipating that we may get an error from the query and we are catching it appropriately, now we can handle it as we need.
Error produced:
Code:
Error in query: Table 'test.categorides' doesn't exist
See clear and it tells you exactly where the problem is. Obviously you may want to control this with some logic that denotes whether the errors get printed depending on the environment (i.e. live/development or staging) Alternatively you could use trigger_error and then when on live use
error_reporting to hide the errors that may occur in the live environment (which shouldn't really happen but its a good fail safe, as its a bit insecure to let your application fart errors out on a live site)