PFMaBiSmAd

<?php phpinfo(); ?>

The code inside your while(){} loop is reusing and overwriting the $dres variable so when the while loop condition is reevaluated after the first pass through the loop, $dres is no longer the result resource from the first query.

You can only change the setting in the master php.ini. Do you have access to the master php.ini on your server?

Best guess is that your code is dependent on a php.ini configuration setting that is allowing it to work on your development system but not on your live host. You could also have a session setting problem on the live host. I would recommend temporarily setting error_reporting to E_ALL (it should already be this value) and display_errors to ON so that all the php detected errors will be reported and displayed.

Ummm. If you are in a programming class and are expected to use a specific server and that server does not have the error_reporting/display_errors settings set up or they cannot be setup to give you the most HELP possible while learning, developing, and debugging your code, you have got to ask yourself if you are in the right class. Learning, developing, and debugging php code without the help from php's error_reporting is kind of like a blind guy driving a car on the highway. You might eventually get where you are going (produce some working code), but it is going to take you a very long time (at least 10x longer) and when you get there you will be all bloody and beat up (you will have wasted a lot of effort on just getting your code to run and with not much effort actually going into the coding.) P.S. You can install Apache/PHP/mysql on just about any personal computer/laptop that has a supported operating system.

I don't see any code that is setting $id to a value before you execute the following statement - $details = $upload->getFileInformation($id);

That's because that code will display that message any time the query executes with no errors (which we already knew because the or die(...) was not outputting anything.) Going back a few steps, your code does not have a session_start(); statement so you cannot reference a $_SESSION variable (doing what BlueSkyIS has suggested, twice, will help you since you will see what the query actually is.) You are also not checking if the form was submitted or validating any of the form data, which might be empty if your form is invalid or has not been submitted (doing what BlueSkyIS has suggested will also let you see if the form values actually have what you expect in them.)

^^^ Telling us that something won't work is pointless. We already know that since you are posting on a help forum. You have got to tell us exactly what symptom you observed in front of you when you tried it.

You generally would need to export your data, truncate the table, and re-import the data. The reason there is not a built-in function to do this is because once you assign identifiers to data, changing those values will causes problems in MOST real applications. It also requires a large amount of processing that makes it impractical in real applications that must remain functional at all times. The database does not care if there are gaps and you should not care either. If gaps are an actual problem in what you are doing, that is an indication that you are using identifiers incorrectly in your application.

^^^ That's generally referred to as using the argument itself. It sounds like you should not be using a default for the argument in question. You are expecting your function definition to perform logic that your application code should be doing.

On a development system, you would typically set those in the master php.ini so that parse errors will be reported and displayed as well (setting those in your script will only show fatal runtime, warning, and notice errors.) Stop and start your web server to get any change made to the master php.ini to take effect and use a phpinfo(); statement to confirm that the settings actually changed in case the php.ini that you changed is not the one that php is using.

You should be developing and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON so that all the php detected errors will be reported and displayed. You will save a ton of time. The nonexistent $SQL variable would have produced an undefined error message that would have alerted you to a problem with it.

The error message you are getting is because you are not using the same variable to form your query and to execute your query. $sql is not the same as $SQL

<?php $confirmed[] = Array('AAAAAA-BBBBBB',2,'2010-09-29'); $confirmed[] = Array('AAAAAA-BBBBBB',2,'2010-09-28'); $confirmed[] = Array('CCCCCC-DDDDDD-EEEEEE',3,'2010-09-29'); $seperated = array(); foreach($confirmed as $arr){ $parts = explode('-',$arr[0]); foreach($parts as $part){ $seperated[] = array($part,$arr[1],$arr[2]); } } echo '<pre>',print_r($seperated,true),'</pre>'; ?>

^^^ Then why did you use GROUP BY in the first place? What end result are you trying to achieve, because combining data only to undo it later wastes a lot of processing time. I suspect that you just need to ORDER BY the correct column(s) and iterate over the data in your presentation logic.

^^^ If mysqli_error() appears that way in your actual code, when you get a query error, that mysqli_error() statement will produce an error of its own because it requires the $cxn (mysqli link) as a parameter.

Please don't use addslashes() to escape data being put into a query. It is possible to use character encoded data that will allow quotes to be injected into a query that will pass right through addslashes(). This is why magic_quotes_gpc (which simply uses addslashes() internally) is being removed from php and why the the mysql(i)_real_escape_string() function exists (it takes into account character encoding when escaping data.) See this link for a demonstration of how addslashes() can be bypassed - http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string Edit: And in fact there is a link in that information to an article that demonstrates under what conditions mysql_real_escape_string() can be bypassed. This mysql_real_escape_string bypass was apparent corrected in php 5.2.3 -

You should be developing and debugging php code on a system with error_reporting set to E_ALL and display_errors set to ON so that all the php detected errors will be reported and displayed. You will save a ton of time.

Your links are using catid. Is catid the same as listid, which is what you are using in the DELETE query?

Just about anything is possible in programming, as long as it makes logical sense. You must fetch data from the result set of a query. In your code, that does not happen until later (after you are checking if the number of rows is greater than zero.) You would need to rearrange the logic so that your program accomplishes what you have stated you want it to do.

From the 1st line of your code to the line with echo $year, there's no code setting $year to any value so it will be a little hard for it to display anything when echoed.

Functions and class methods have parameter lists for a reason, so that you can pass them parameters at runtime.

I edited my post above with this information - For functions to be useful and reusable (unless you want to keep rewriting and testing them every time you need to change something in the main program), they must operate as black-boxes with zero interaction with the main program except through the parameters they are passed and through the value they return.

@rwwd - using the global keyword to pass anything into a function is bad advice. The reason the function code is failing is because the $tbl_users variable does not exist inside the function. For the record (how many times have we written this) - Just putting function some_name(){} around a block of code does not make that code into a function. You must design a function to perform some specific operation and define the (optional) input parameters, define the processing it will perform, and define the results it will return to the calling code.

I would set them in your master php.ini so that parse errors would also be reported/displayed. Stop and start your server to get any changes made to the master php.ini to take effect and use a phpinfo(); statement to confirm that the values actually changed in case the php.ini that you changed is not the one that php is using.