PFMaBiSmAd

The script you are using probably came with either an installation script that would create the necessary tables or a .sql database script file that you need to run in your database manager. What do the installation instructions that came with your script say to do?

You can make the above query a little more efficient by throwing in a WHERE clause so that only records greater-than or equal to three months ago are used.

You didn't show what your date format was. You should store dates using the DATE data type, that's what it is for. Doing so will allow you to directly sort, order, and do greater-than/less-than comparisons on the values. Your data will also take up less storage and your queries will execute faster and will easier to write.

SELECT User_id, MAX(Create_Date) as max_date FROM records GROUP BY User_id HAVING DATE(max_date) BETWEEN DATE_SUB(CURDATE(),INTERVAL 3 MONTH) AND DATE_SUB(CURDATE(),INTERVAL 1 MONTH)

The error means that php reached the end of your file while it was still expecting to find some php code. This is due to an opening element that is not closed, usually a { that has no matching }. However, it can also be due to strings that are not closed. If your {} are matched, I suspect that one of your your heredoc closing tags isn't the only thing on a line and/or doesn't start in column one of the line. Edit: your issue might also be due to having <?php ?> tags inside your heredoc strings (now that I see the code highlighting and where it stops at in your source code.)

You can access the username property using either - $_SESSION['customer']->username or after you assign $username = $_SESSION['customer']; using - $username->username However, I suspect that $_SESSION['customer'] is supposed to be an instance of a customer class, had the class definition existed before the session_start() statement. You need to find where $_SESSION['customer'] was created and at a minimum the person who wrote this code should have given you a list of the classes and the definition of the properties and methods of each class.

Add the following code right before the $username = $_SESSION['customer']; line to find out what $_SESSION['customer'] contains - echo "<pre>"; var_dump($_SESSION['customer']); echo "</pre>";

$_SESSION['customer'] must be an instance of a class or an object. Are you trying to access a method or a property of that class to get the username?

Yes. But does a phpinfo statement show those are the actual settings being used by php?

Those are comments telling you what the suggested values should be. Those aren't the lines that are setting the values.

Once you leave that page, there is nothing that indicates that the visitor has authenticated him/her-self against your database table. You need to set a $_SESSION variable that indicates the visitor is logged in (usually his id from your user (merchants) table.) You could store the URL into a session variable to indicate this.

Each page that you want to protect must test the $_SESSION variable(s) that your login script sets to make sure that the visitor is logged in and is allowed to access that page.

You should set the error_reporting/display_errors settings in your master php.ini on your development system, so that you don't need to remember to put them into your code or remove them when you put your code onto a live server (display_errors should not be ON for a live server.) Setting them in your master php.ini will also get php to display fatal parse errors (putting the settings into your script won't show fatal parse errors because you script never runs and the lines of code to change the settings are never executed.) Just because you can set $_SESSION variables at one point in your code (just requires that the session_start() worked), does not mean that a setcookie() statement will work at that point in the code. If you output any character(s) to the browser before the setcookie() statement, it will prevent the setcookie() from working.

So, are you developing and debugging this 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. I'll guess you are getting a header error that is preventing the setcookie() from working. You also might be changing the path or the host-name/subdomain (www. vs no www. on the URL) in the URL from where the setcookie() statement is at and the cookie is not being sent back to the server from the browser. See the 4th and 5th parameters of the setcookie() statement. You also might have the setcookie() statement inside of some conditional logic that is FALSE and the statement is not being executed. When kenrbnsn asked for the code where you are setting the cookie, he did not mean just the setcookie() statement. He meant all the code that would show when and where you are setting the cookie.

That contains no useful information about what you saw in front of you. Someone could easily name 12 different things that happened when you tried your code, but without any information from you about what symptom you saw to narrow down the possibilities to just one or two of the most likely causes, no one is going to sit here wasting time guessing what "it did not work" means.

^^^ I have no idea what that means, but you would need to post your current code if you need help with something it is doing. Also, posting the output you are getting would help.

So, did the suggested use of mysql_error() in the die(...) statement, that Pikachu2000 posted, produce a mysql error message? And, there are two different queries that could have been producing the original "Query failed" message and you would need to alter the code for both of them to insure that you get an mysql error to be reported for the one(s) that fail.

What you posted works and prints 1,234.50 If it doesn't work for you, then you would need to post your actual code that demonstrates the problem.

I don't recall anyone stating that you cannot get sessions to work when cookies are turned off.

By default, the session id is passed using a cookie. It is best to use it this way. The only other choices are to pass that session id on the end of the URL or to pass it as hidden form data (assuming there is a form.) Since php will only automatically pass the session id on the end of relative URLs on your site, you end up writing code yourself to insure that the session id gets passed as part of the URL in all cases and if someone leaves your site, the session will be lost if the URL looses the session id on it.

If you are dynamically building up some data on one page, you would generally use a session to pass that information, for the duration of a browser session for one visitor, between different pages or requests for the same page. If you need that information to persist longer than one browser session or for it to be available to different visitors, you would generally store it in a database table.

Yes, but your script is NOT still running at the time your form gets submitted. Web servers are stateless. They don't know or care what happened before the current http request or what will happen after the current http request. They blindly service each http request they receive. When they finish servicing one http request, all the resources used on the page that was requested are destroyed. They are not sitting there waiting for a form to be submitted because they don't know or care what is on a web page, they just output the web documents that get requested. Here is what happens when a form is requested and that form is submitted - 1) A http request is made for a page that happens to output the html that makes up a form. The web server reads the file that corresponds to the page that was requested and outputs it to the browser. If that page happens to contain any php code, that php code is parsed, tokenized, and interpreted. Any output that the php code produces is sent to the browser. 2) The browser receives the html that was output by the server and renders it. If that html produces a form, you now have a form sitting in front of the visitor. 3) When or even if that form is finally submitted, it is submitted to the URL that is in the action="" attribute in the <form> tag. This results in a http request to that URL and hopefully there is some php code on the page that gets requested that will detect and process the submitted form data. This http request is completely separate from the http request that caused the form to be output to the browser. The only thing that ties the two http requests (form and form processing) together is the information that comes as part of the http request. This includes the IP address that the request came from, any cookies (including a session id cookie), information that is part of the URL, and any information that is submitted as form data. Edit: Short-answer: Even if your form and your form processing code are on the same page, each request for that page is completely separate. It is up to the logic you put onto that page to decide what to do for any particular request - output the form or detect and process the form submission.

It's not necessarily a matter of finding better code, it's a matter of troubleshooting the problem is that is preventing the code you already found or wrote from working, because whatever was preventing your existing code from working will likely prevent any other code you find from working as well. You will just keep throwing away code and never get anywhere. In fact, most of the php code you will find posted around on the Internet that claims to be the 'greatest' login script ever created either won't fit your needs and will need to be modified or is a piece of crap and won't work or will have security problems. Here is a link to a popular login script, but I recommend that you replace all the short open php tags in it with full php tags so that it will function regardless of the php tag setting on the final server it is used on - http://evolt.org/node/60384

You can do this all with a single query - http://dev.mysql.com/doc/refman/5.1/en/insert-on-duplicate.html

Either you have some prior code on that page that is adding those entries to the $emails array or there are actually that amount of data in the database. How about initializing the $emails array right before the start of that block of code - $emails = array();