PFMaBiSmAd

$ibforums->input['t'] is a numerical value, probably an integer. You would need to cast it as an integer at the time you put it into the query statement to prevent whatever sql injection, that you didn't bother to post the example of, is occurring. Using mysql_real_escape_string on an integer value in a query would not prevent sql injection since the type of sql injection that does not use any quotes would not be affected.

If you want our specific help, you would need to post the code getting the data for and building the the query statement along with the offending query.

What? I have no idea what that refers to. http_build_query is a general purpose way of building a query string and letting you add/set/remove just the get parameter(s) that you are interested in, while leaving any/all other get parameters as is. The only time I have ever needed to add any extra logic is when you dynamically remove (unset) a get parameter and it could have been the only get parameter and you want to avoid putting a bare ? on the end of the URL (the string that http_build_query returns will be empty if there is no resulting query string built.) Here is a specific example of this - <?php unset($_GET['logout']); // remove logout parameter from the url $request = http_build_query($_GET, '', '&'); $request = !empty($request) ? '?'.$request : ''; header("Location:{$_SERVER['SCRIPT_NAME']}$request"); // redirect to the base page (without the ?logout on the URL) die; // prevent the remainder of the code from running while the browser performs the redirect

See this link - http_build_query You can set/unset just the $_GET['variable_name'] you are interested in, then use http_build_query to build the query string that you place after the ? in the URL. This will leave all the other existing $_GET variables as is. Edit: Here is a specific example showing how to use this in a pagination script that only modifies the 'page' parameter in the get parameters, but leaves a 'keyword' (search) value as is - http://www.phpfreaks.com/forums/index.php?topic=348834.msg1646676#msg1646676 If you are going to be using this in a header() redirect, you would use a '&' as the 3rd parameter instead. Using '&' for the third parameter is for when you output links directly in the html on a web page.

Your HTML markup is missing the quotes that go around the value=" " attribute.

Here's the information that someone has suggested looking at -

The case-sensitive problem is due to the integer account_number column and the use of concat() -

Of course. Rearrange the logic so that the form processing code comes first, then the code that gets and displays the content on the page.

Are you seeing session data disappearing in less than 24 minutes of inactivity? Are you on a shared web host?

According to your thread title and this - You are trying to UPDATE multiple rows with new values. In order to do that, you must identify in the update query which row to update with which value. For an UPDATE query inside of a loop, the WHERE clause would indicate which row each UPDATE query operates on (see the code that Pikachu2000 posted.) For my suggested method #1 (I'm not even going to attempt to show a query using suggested method #2), you would dynamically build a query that looks like - UPDATE products SET position = CASE WHEN id = 245 THEN 2 WHEN id = 1313 THEN 1 ... repeat for each id/value ... ELSE position END WHERE catId = $catId Each WHEN id = x THEN y term associates the id of the row with the new value to put into that row. The ELSE position term is so that row(s) that you don't supply a new value for get updated with their existing value. The WHERE term is not actually needed, but I left it in the query so that the query does not evaluate every row in your table.

That kind of depends on what your template is and how you want it to display. What have you defined you want and what have you tried when you attempted to do this yourself?

<?php $from_date = '2011-12-16'; // get your dates from your table into php variables $to_date = '2011-12-31'; while($from_date <= $to_date){ echo $from_date . '<br />'; // produce and output what you want here... $from_date = date('Y-m-d',strtotime("$from_date + 1 day")); // increment the date }

Back to your concat() method. If any of the columns are binary strings or numerical data types, the result is a binary string and the comparison will be case-sensitive. The mysql documentation for the concat() function shows how to cast any such fields to a CHAR type so that the resulting comparison would be case-insensitive.

You could just set session.gc_maxlifetime to a longer reasonable value. The purpose of session.gc_maxlifetime is to delete old session data files, not to prevent users from actually using your pages that rely on session variables.

If you didn't get any php errors out of this, then your web host has likely disabled ini_set/error_reporting or you have used your own error handler and didn't take into account all the types of errors. Also, don't ever use lazy-way short opening <? tags. They WASTE several orders of magnitude more time then you ever saved in typing time by leaving out the three letters 'php' a few times per code file.

Register_globals magically populated php program variables (i.e. $some_variable_name) from the same name $_POST, $_GET, $_COOKIE, $_FILES, $_SESSION, and some $_SERVER variables. In the case of $_SESSION variables, setting a php variable with the same name as a session variable also back-populates the $_SESSION variable, which unfortunately means that a hacker (when register_globals are on) can set any of your session variables with any value he wants by supplying any of same name post,get,cookie,... variables when he requests your page (a lot of web sites have been taken over because this allows session based security to be bypassed, mainly when included files are directly requested.) To convert your code, you generally need to do two things - 1) Any php program variable that is actually coming from one of the $_XXXXX sources that I listed needs to be changed to that actual $_XXXXX source. The most straightforward method would be to add an assignment statement from the correct $_XXXXX source to the php program variable, for example: $some_variable_name = $_POST['some_variable_name']; 2) Any use of session_register(), session_is_registered(), and session_unregister() must be changed to set/unset or reference the correct $_SESSION variable instead, along with adding a session_start statement before anything is output on any page that sets or references a $_SESSION variable. Identifying the correct $_XXXXX source is the hard part of doing this, because you must have and be familiar with all the source code so that you can track down where and how a page gets requested so that you can determine where each variable name is actually getting set from (this is also why writing code using register_globals actually took more time and effort because in large applications you needed to make sure you weren't reusing variable names and then the time needed to troubleshoot unexplained variable problems when you did reuse a name.) If you set php's error_reporting to E_ALL (or even better a -1) and display_errors to ON in your master php.ini on a development system, php will at least help you find variables that are no longer being magically set by register_globals (they will produce undefined variable error messages when they are referenced.)

If register_globals are not on, they are not causing the problem and you can forget about everything you have heard about them because they are finally being removed in php5.4 (soon to be released.) How exactly are you distinguishing these 'different' web sites? Sub-domains? Different domain names mapped to different folders? Different scripts that are just in different paths under one domain name? If the session name and session id cookie value match for all the scripts running under one domain name, you will have ONE common session. If you are using sub-domains, you can set the session cookie domain setting so that the session id cookie will only match the sub-domain where it was created. For different domains, you should not have any problem as (all) cookies are domain specific. If you have different scripts under one domain that both use session variables but should not share the same session, using different session names (the default name for one of them and a specific different name for the other) for each script would be the simplest solution.

Do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would report and display all the errors it detects, such as a problem with the session_start?

The example query you are posting in an attempt to show us what you are trying to do is meaningless as an example to show us what you are trying to do because the WHERE clause only refers to ONE row. You would be updating the same row over and over. You would only have the last value in the row after the code executes. Do you have an actual example of what you are trying to accomplish that shows which piece of data gets updated into which row?

There are two ways of performing a mult row update - 1) Use an UPDATE query with CASE ... ELSE ... END logic to supply the SET column = value for each different row, 2) Use a multi-value REPLACE query. Do you have a specific example of what you are trying to accomplish (I don't believe your sample query with a single catId value.)

It's not the assignment of the variable that is causing the header error, it is the referencing of a nonexistent variable that is producing a php error message that is causing the header error. You would need to fix the logic so that you don't attempt to reference an nonexistent variable in the first place.

Are you even using <?php tags in your code? What does a 'view source' in your browser of the page show?

Your file being included probably contains a fatal parse or runtime error, due to a configuration difference between your development system and the live server. Add the following three lines of code immediately after the first opening <?php tag in your MAIN file - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(-1);

Unfortunately, if output_buffering is turned on in your master php.ini, any php errors that are output before the header() redirect, won't be. You are using the $id_client variable before you have even assigned a value to it. You should only be redirecting after you have successfully performed all the logic on the page, not as the first thing on the page. If output_buffering is turned on in your php.ini, you should turn it off ASAP, especially on your development system.

Perhaps if you consult your previous thread on this - http://www.phpfreaks.com/forums/index.php?topic=350579.0