mac_gyver

the errors in post #3 are because there is no session to destroy after you execute a session_write_close(). rather than just listing a bunch of session related functions in your code, you actually need to define what you want to accomplish and write just the code that does what you have defined you want to do. many of the statements you put into your code don't have anything to do with clearing session variales.

if you had tested if the ->prepare() worked, you would have likely gotten an error about an unknown table name... you need to test at each step that can fail or in the case of PDO you can configure it to throw an exeption at any step that fails and it will goto the catch statment upon the first statement that fails.

i would guess your current problems is that you are redirecting at some point in the code and any output you might be sending is being buffered and discarded so you never see it. two things - 1) you need to make sure output_buffering is turned off in your php.ini 2) comment out any header() redirects until after you get your code to do what you want.

your first SELECT query is finding any result in the current month with any true year value. that has nothing to do with checking if there is an event on any day. the second query is all you need. you would then test if the number of rows from that query is less than one. if it is, there isn't any event on the current date. also just use WHERE Events.Event_Date = CURDATE() in your queries.

the symptom of any "refresh, redirect, or navigation" loosing the logged in state most likely means that sessions aren't working at all. the code on your page may indicate a successful login, but that only means the code on that page authenticated the user, not that the session was created. do you have php's error_reporting set to E_ALL and display_errors set to ON or log_errors set to ON so that you would be seeing/logging any session related errors? have you checked in the browser if the session id cookie is being set and does it have the expected settings? have you checked if a session data file that matches the session id cookie is actually being created? have you checked if the data stored in the session data file is what you expect (you may have a logic error or something like php's register_globals combined with a user_id cookie that is causing the session data to be overwritten)?

and did you refresh your form to get the change to take effect in the html in the browser?

SELECT customer_id FROM your_table GROUP BY customer_id,supplier_id HAVING count(*) > 1

your form doesn't have a field named 'submit' and as a result your form processing code is being skipped over.

that error, if you had searched for it, means that you have some opening php syntax that is not closed before the end of your file. this is generally due to a missing closing } but can also be due to a missing closing quote on a string... even ignoring how the forum software messed up your posted code, you need to properly indent your code (all the lines of code that are between matching { } should be indented the same amount, this lets you see where there are missing }) and eliminate the excessive blank lines and white-space in it.

something else to consider while 'upgrading' this code. the OLD mysql_ database extension is depreciated starting in php5.5 and database functions should be upgraded to the mysqli_ or the PDO database extensions.

also, your $stmt->bind_param() statement is incorrect. the first parameter needs to be a string consisting of the data types. your series of threads in the forum show a lack of understanding or of just copy/pasting things without understanding what they are. i recommend you slow down and read a good php/mysql book or tutorial or the examples in the php.net documentation. @fastsol, the variables can be defined/assigned values after the bind statement. the variables are bound by reference and are actually evaluated when the ->execute() method is called.

http://dev.mysql.com/doc/refman/5.6/en/example-maximum-column-group-row.html

try this - $x = 1; // incrementing field name/number if($JECT && $JECT!="no"){ $itemcode1=$JECTitemCode; $itemprice1=$jectprice_hidden; echo "<input type='hidden' name='itemcode$x' value='$itemcode1'> <input type='hidden' name='amount$x' value='".round($itemprice1,2)."'>\n"; $x++; } if($JCTL && $JCTL!="no"){ $itemcode1=$JCTLitemCode; $itemprice1=$jctlprice_hidden; echo "<input type='hidden' name='itemcode$x' value='$itemcode1'> <input type='hidden' name='amount$x' value='".round($itemprice1,2)."'>\n"; $x++; } if($LCJ && $LCJ!="no"){ $itemcode1=$LCJitemCode; $itemprice1=$lcjprice_hidden; echo "<input type='hidden' name='itemcode$x' value='$itemcode1'> <input type='hidden' name='amount$x' value='".round($itemprice1,2)."'>\n"; }

sorry to jump in here. but you have too much logic, making it hard for you to see the forest for the trees. the variables $JECT, $JCTL, and $LCJ contain either the string 'yes' (apparently for a renewal), 'no' (don't renew), or one of the listed choices (i.e. add/start a new subscription for 'JECTindividual_print'). at the point of your case/switch logic, a !="no" condition means either a 'yes' (renew) or one of the listed choices (add/start). a !="yes" condition means either a 'no' (don't renew) or one of the listed choices (add/start.) so if someone does pick one of the listed choices for the three variables, that will match one of the first three case statements and the rest of case statements are never ran due to the break; statements. if all you are trying to do is add one to three sets of form fields, with incrementing itemcodex, amountx fields, just use a variable $x that gets incremented, then have a set of if(){} logic, one for each of the $JECT, $JCTL, and $LCJ variables, testing for the !="no" condition. [rant] using an array and generic variable names, would have allowed you to have any number of different products with at least 1/3 the amount of code needed to produce the form and process the data.

concerning using a persistent connection to 'help' your current code. a persistent connection is only persistent when php is running as a server module (this is not common, php is most commonly running as a CGI application) and for only some versions of php/php's underlying database client library. in all other cases, trying to use a persistent connection only results in a regular connection.

this would be something that you can benchmark yourself, using the database library you happen to be using, which you haven't mentioned. each time you open a database connection, requires some overhead (the brief list of tasks performed was mentioned in your last thread on this subject.) if you are doing this x times during the execution of any one script, all the processing time taken after making the first database connection is wasted. it should be noted that closing a database connection also has the overhead of shutting down the instance of the database client on the php side and for the database server to actually shut down the process it started to service the connection the server side. i think you are misunderstanding how interrupt driven, multitasking operating systems work and how services/servers work. just because you have a database connection open, doesn't mean you are 'tying' up the database server for the length of time that connection is open. it's not your job to minimize the amount of time you are connected to the database server, its your job to minimize the amount of processing cycles you are using. the database server only performs an action when it has received a set of data packets that form a complete command/query from the client (php in this case.) this communication is handled using interrupts. there can be any number of concurrent open database connections (limited by the - max_connections setting) from any number of different clients. the total amount of data packets and the total number of commands/queries determines the load on the database server. doing anything that increases this load is undesirable, such as opening and closing a database connection for every query.

the code you posted ISN'T where the problem is. you proved that yourself when you browsed directly to it. the problem is in the other file that is including this code. if you cannot determine what in the other code is causing this, you will need to post it or hire someone to fix this for you.

if you mean you are increasing the session.gc_maxlifetime setting, you must do that before every session_start() statement and if you are on shared web hosting and using the default tmp location for the session.save_path setting, you must set your session.save_path setting to point to your own folder so that your session data files won't be affected by the session.gc_maxlifetime setting of any of the other accounts using the tmp folder.

your code that you didn't post showing how you are including the file, is likely including the file twice or including it in a loop and it likely doesn't have any $tid array the first time it it is included/looped over so you only get the initial table heading and not the result form the foreach($tid ...) loop. also, $tnumber isn't an array. how come you are trying to reference it using array syntax $tnumber[1]?

use - $current_date->modify("+1 day"); and DavidAM's code should work. straight forward code that loops over all the days in the range, testing if the current day of week is one of the desired days, is better in this case than trying to account for the starting day of the week, that can be anything, and needing to get that starting day up to one of the desired days of the week, then to get the current pointer to the $days array to that same value in order to get everything in sync before you can even start to actually loop to produce the result.

the one = in your if() statement is assigning null to the variable, not testing if the variable is equal to a null.

when you echo $map, what does the 'view source' of that look like in your browser? and what is your code that is building the specific link with that value in it?

you are trying to build a link - <a href="some_url">some_content</a> where the some_url is the corresponding url of the large image and the some_content is your <img ...> tag of the thumbnail. your code is already producing the <img ...> tag, just output the <a ...></a> tag/link around it.

when there's an upload error (most commonly due to exceeding the upload_max_filesize setting), all the elements of the $_FILES array will be set, though most of them will be empty. you need to test if the upload worked before you can reference any of the uploaded file information. test if $_FILES["photo"]["error"] is set and is equal (two == comparison) to zero or alternatively you can test if $_FILES["photo"]["error"] is exactly equal (three === comparison) to a zero.

http://dev.mysql.com/doc/refman/5.6/en/date-and-time-functions.html#function_from-unixtime