mac_gyver

after you browse to the first page, look in your browser's 'page info' for that page and check if there is a cookie with the name PHPSESSID (the value in the cookie should match the session_id() value.) have you by any chance disabled cookies in your browser settings? i see a stray { on line 4 of the first posted code. is the code you have posted all your actual code? i.e. you could be doing something that is un-setting the session data somewhere else in your code.

you need to have php's error_reporting set to E_ALL and display_errors set to ON so that php will help you by reporting all the errors it detects. you could have mis-configured session settings that are preventing the session data from being saved or a php file that is saved with a bom (byte order mark) characters that are then being output prior to the session_start() statement. both of these will be reported by the error_reporting/display_errors settings. some other possibilities are the host-name/sub-domain part of the url (www.domain.com vs domain.com) is changing between the two pages (by default the session id cookie only matches the variation of your domain where it was set) or even the path after the domain is changing (by default the session id cookie should match all variations of the path after your domain in the url, but your setting could be different than the default.) are these two files in the same folder and is the usage of the www. or no www. consistent in the urls when you move from the first file to the second one?

your development system as a (nasty) php setting turned on that allows poorly written code to work, but makes it non-portable between servers. you need to turn off output_buffering in your php.ini on your development system so that the code you produce will work, with respect to header() statements (which sessions also use for the session id cookie), regardless of the server you try to run your code on.

not too many people are going to visit an unknown site posted in a forum and login just to observe the symptoms. also, seeing the problems occur from the client side doesn't tell us what the server side code is doing, which is where the session is being maintained. about the only things you can do from the client side would be to check if the session id is changing (which it might intentionally be doing if you are regenerating it, so that won't even tell us anything) or if your page is redirecting/refreshing and the url is changing in such a way as to no longer match where the session was first started. the fact that a stripped down version of your code still exhibits the problems says the problem is somewhere in your core code, which we still haven't seen.

another possibility is when you edited the php.ini file, it got saved as php.ini.txt and is no longer being used by php (all the default settings would be in effect.) what does the phpinfo(); output show for the Loaded Configuration File value. it should be the php.ini that you edited.

there should have been no need to uncomment anything, just change values in settings. it's likely you uncommented part of the description of what the setting does, not the actual setting. you should end up with two lines somewhere that look like - error_reporting = E_ALL display_errors = On

this is the pseudo code that Barand handed you - if a call value was posted query table if no records display no records else display results end if end if this is the implementation of that logic - // this assumes you have done any filtering/validation of the $call value prior to this if($call == ''){ echo "The search term is empty."; } else { // a non-empty search term was submitted $call = mysqli_real_escape_string($con,$call); $sql = "SELECT * FROM qsolog WHERE `call` = '$call' "; $result = mysqli_query($con,$sql); if (!$result){ die(mysqli_error($con); // there's no point in producing follow on errors if the query failed due to an error } if (mysqli_num_rows($result) == 0 ){ echo "No records found<br>"; } else { // one or more records were found // output your table heading here.... // loop over the row(s) the query returned while($row = mysqli_fetch_assoc($result)) { // output the table data here... } // end your table here... } }

you need to stop creating new threads for the same problem. you also need to determine exactly why the logout occurs. it's more likely that you are changing the host-name/sub-domain part of the url (www.domain.com vs domain.com) due to the multiple page requests/responses and the session is no longer matching the url of the last page request. to reiterate something from one of your earlier threads about this problem - nothing a user can normally do on a site should cause them to be logged out. if you have such a problem, you need to find what is causing it and fix it. putting a band-aid over the top of the problem, such as trying to prevent double-clicking doesn't fix the problem and won't work in all cases. the problem is not being caused by the double-clicking. that's just a symptom. the problem is what your code is doing in response to the multiple page requests.

i'm wondering what environment you got the fatal error in post #5 in? syntax errors in the php.ini will prevent the remainder of the php.ini from being parsed. i suspect that when you changed the error_reporting/display_errors settings you introduced a syntax error in the php.ini and none of your enabled extensions are being loaded. edit: in this case, the web server's error log should (untested) contain a php error message about a problem with the php.ini.

by using htmlspecialchars or htmlentities on data being put into a query statement, the data is altered. for this specific example of a search value, that would require that the data that is stored in the database to also have htmlspecialchars or htmlentities applied to it. for doing things like bulk importing of data using a load data infile query, that's not possible. short-answer: data should be stored as the actual unaltered data value so that it can be used in any context, not just to be output on a html web page. the conditional suggestion for the stripslashes was to do this in code - // Usage across all PHP versions if (get_magic_quotes_gpc()) { $some_variable = stripslashes($some_variable); }

mysql and mysqli are two different library's of database functions. you need to pick one and use it throughout your code. the mysql extension is depreciated starting in php5.5 and should not be used when writing new code as you will need to rewrite it in the future when the mysql extension is completely eliminated. the php.ini line you posted has nothing to do with enabling the mysqli extension. it is a setting that enables a load local infile query. assuming you are using windows, the line to enable the msyqli extension would be - extension=php_mysqli.dll

if you are getting a fatal error about the mysqli class, it means that the mysqli extension is not loaded in your php.ini configuration and each page attempting to use mysqli was failing.

several points about your sanitize function. 1) trimming data should be something you do depending on what the data is and how it will be used. 2) you should ONLY use stripslashes on incoming data if php's magic_quotes_gpc setting is on. unconditionally using it will prevent actual \ characters in the data. 3) htmlspecialchars or htmlentities should ONLY be used when you output data to the browser, not when the data is input. 4) you should only escape functions on string data and ONLY right before you use it in a sql query statement. 5) numerical data needs to be validated/cast as the appropriate numerical type. using an escape string function on numerical data, when it is used correctly in the sql query statement, won't prevent sql injection.

in programming, you cannot assume anything. the parameters of the mysqli function calls are different from mysql. a way to avoid the confusion between mysql and msyqli is to use the object notation for mysqli (which actually results in shorter syntax.) i'm not sure why you had any mysql functions in your code. weren't you using mysqli all along in these series of threads?

i recommend that you read/scan through the pdo section of the php.net documentation so that you are aware of the different things it can do. again, this is the basics and array variables would be/are covered within the first few chapters of the php.net documentation, a basic php book, tutorial, or class.

that's not how to call mysqli_real_escape_string. i'm pretty sure you will have had it suggested in one of your threads or have read a thread where it has been suggested that you have php's error_reporting set to E_ALL and display_errors set to ON to get php to help you.

the resulting array contains 3222 numerically indexed sub-arrays of data. the foreach loop would be - foreach($json_arr as $arr){ // your code to reference the elements of $arr }

all the null/false values are because the data isn't being fetched as an object (there would be php errors like Notice: Trying to get property of non-object in ..., so you don't have php's error reporting set). have you configured pdo to fetch the data as an object? you either need to do that or use array notation to reference the $row values.

this is a (very) common error. did you search for it to find what it means and to find out how to determine what is causing it? see this link - http://forums.phpfreaks.com/topic/273121-readme-php-resources-faqs/?do=findComment&comment=1428660

i'm fond of using data arrays to define values that generic code then uses so that you don't need to go in and find and edit the actual program logic just because you want to change some data points. this also leads to more code reuse/DRY since the processing is often the same, though the meaning of the variables change.

you need to tell us what it is producing as output as that will narrow down the possibilities, even a blank screen is an important clue. your code has no apparent error checking logic in it. the easiest method is to enable exceptions after you make the database connection, then use a try/catch block to handle runtime errors. also, do you have php's error_reporting set to E_ALL and display_errors set to ON so that php would be reporting and display any errors it detects?

your url contains some $, which when inside a double-quoted string are treated as php variables. you need to have php's error_reporting set to E_ALL and display_errors set to ON so that php will help you by reporting all the errors it detects. you can correct the current problem by switching to single-quotes around the url string.

the following is the part of the book you will eventually read about SELECT queries, with the needed part highlighted - a WHERE clause is used to pick which row(s) a query matches. also, if you expect a query to at most match one row, you should not loop over the result set, just fetch the one row.

for my point #3, you are NOT calling functions, those are variable names you are using in your code $lu2; , they are not function calls, which would look like lvl2($mysqli); and again, your code is not doing anything because of that. also, by calling all those functions up front, you are messing with the values stored in your database table.

some comments about the coding style you are showing in this code. 1) you need to use complete words for your functions and variables that describe what the function or variable is for. you might know what these cryptic names mean now, but a month from now, you won't when you need to quickly find a problem with the code. by using complete words, your code will become self-describing/self-documenting. this will both help you AND it will help someone who you might be asking for help in a forum. 2) it's likely your series of functions are getting different pieces of data for the current user? if so, you should just get all the data at once using one or as few queries as possible. the code you have shown with 11 different function calls, is 'killing' your database server. for a game script, this will end up limiting the number of simultaneous players to a small value (around 10 based on previous threads people have asked help with) and make your web host upset at you for using too many server resources. 3) your code contains stray variables on a line by themselves - $lu2; that doesn't actually do anything, which is possibly the cause of your symptom. by doing these items, we will be able to tell by looking at your code, what it is trying to accomplish, so that we might be able to help you. as it is, we don't a clue what your cryptic logic is supposed to be doing.