Larry

If neither cookies or local storage are available, you could create a session-like database, yes, but then you'd have to append the session ID to every page so that the session ID is stored in the client's history and is usable again when the page is next viewed. You cannot use real sessions for this, as real server-side sessions are only intended to last for a short time.

I'd like to see the actual error message and the details about the installation. $_SERVER['REQUEST_METHOD'] should always be set, because the page is being requested somehow (either via GET or POST).

You may be missing the point of the delimiter. Literally ANY character or character combination can be used. There is absolutely no difference in the usage between $$ and // or ?? or XY or whatever. It's just a two-character combination used to mark the end of a complete SQL command. The default delimiter is the semicolon. The delimiter gets changed for defining stored procedures so that the default semicolon does not pre-emptively end the command. You can use literally anything for a replacement delimiter with equal effectiveness. The only rule is to use something that wouldn't appear within the command itself, such as the semicolon, the asterisk, a comma, the letter F, and so forth.

It would seem to me that Ajax would be a poor choice here (hopefully I wasn't the one that recommended it!). Tooltips need to be quickly responsive to be meaningful and I would worry that Ajax wouldn't be fast enough. Just a thought... Sounds like a perfect time to use cookies. You can use the title attribute within a span to add a tooltip to any piece of text. In fact, proper all-browser support would suggest that you do this always, and then you'd have no need to use Ajax at all. Just a thought... Keep in mind that local storage isn't reliably supported yet.

I would hope that you could not connect remotely to MySQL, as that'd be less secure. But let us know how you make out and if you need any other help.

I believe MySQL treats an enum as a special type of INT. There's no real security issue here, but I'd just use an unsigned not null default 0 TINYINT. That would be the most efficient.

Yeah, that's the thing about FF: it runs fine if you don't add too many extensions, but it's such a great developer's browser because of all the add-ons, which makes it run poorly. Ah...irony!

Hey Jonathon. I don't use Opera as my primary browser, but I've not had the problems you've experienced. I was using FF as my primary for years, but the performance was terrible and there seemed to be memory leak issues. By mid-day, FF was taking 500MB of RAM! I now use Safari primarily (I'm on a Mac) and Chrome as a secondary. For development I head to Opera or FF.

Using the command-line mysql client is a better option than phpMyAdmin, but maybe one you don't have. You can just create a PHP script that executes the stored procedure and reports upon the results, for testing purposes.

The error you posted above seems to suggest that you saw that error when trying to create the stored procedure. I'd be curious to see what error occurs when you execute the stored procedure. In my experience, stored procedure support in phpMyAdmin is buggy and can vary greatly from one version of phpMyAdmin to another. But if you want to use stored procedures, you shouldn't let that stop you. If you want to give up on the stored procedures, on my main site there are a bunch of posts on converting the stored procedures to standard PHP-MySQL.

I don't personally know of any. I would definitely avoid any ranking sites. That's pretty much where I got all my worst hosts over the years. It's impossible to know which of those ranking sites allow for a paid influence and which do not.

For the benefit of others, could you please share what the problem and solution were?

No problem, you'll get through this and this forum is here to help. My more specific recommendation beyond not trying random things is definitely not to mess with the OS and Web server system unless you absolutely know you have that need and absolutely understand the implications of what you're doing.

In your last post you referred to feedback.html, which is the page you're having a problem with. What I'm saying is, presumably you went through the first two chapters, correct? And presumably you were able to execute those PHP scripts, correct? So, for example, when you successfully ran predefined.php from Chapter 2, what URL did you use for that? So could you please post the complete URL of a specific script from a previous chapter that you were able to execute?

No offense meant at all, but it surprises me that you know about changing ports (let alone how to do that), but you don't know that the MySQL port isn't something you'd use in a URL or that you wouldn't include /Applications/MAMP/htdocs in the URL. Again, no offense meant, but you seem to be doing a weird combination of advanced and very beginner things here. Okay, so if you changed the port to 80, then you don't need to indicate the port in the URL. And also don't have the Mac OS X Web sharing on at the same time, as that uses port 80 by default. Second, the URL localhost already points to the Web root directory. You shouldn't put /Applications/MAMP/htdocs in the URL, as those are file system references. By default, localhost on MAMP points to /Applications/MAMP/htdocs. That is unless you've changed that setting in MAMP.

Okay, a few things... - File sharing has no impact here. Web sharing is the key thing to enable for using Mac OS X's built-in Apache. - If you're using MAMP, then your URL needs to start with http://localhost:8080, I believe. Check the MAMP documentation or view the MAMP Web start page, available through the MAMP control panel. - You absolutely must, always run PHP files through http. I stress this repeatedly in the book. Loading a PHP script through the file system won't do any good. Loading an HTML form that gets submitted to a PHP script through the file system won't do any good. - You'll do yourself a big favor if you stop randomly trying things. You're only confusing yourself and making this more complicated.

Yeah, the file path won't work either. The browser address MUST begin with http://. The "something" part then is the hostname, folder name, and script name. What those are depends upon the OS in use, the Web server in use, the specific script, and so forth. To repeat the question I asked in my last post, what URL did you use to run PHP scripts in earlier chapters?

I think the official publication date is Sept. 19th, but I could be wrong about that. As for the major changes, those are detailed on the book's TOC page: http://www.larryullman.com/books/php-and-mysql-for-dynamic-web-sites-visual-quickpro-guide-4th-edition/table-of-contents/ I also have written about this a lot in the newsletter over the past couple months: http://www.larryullman.com/tag/newsletter/

Okay, to start, a couple of minor things. First, you assign the $_POST variable to local variables at the top of the screen, but then don't use the local variables. I would recommend that you do some validation of the $_POST variables and create local variables in the process. Next, I wouldn't think you'd really want to do a search if the user enters no terms and selects nothing. Or should that be the "all" supplier option, in which case you have 7 possible scenarios, not 8? Next, you have 7-8 scenarios, but you really only have one query, which always selects the same data and always uses the same ORDER BY clause. The only difference is the WHERE clauses. I'd simplify the structure by playing off that fact. The only thing you have to watch out for is when to use AND or not in the SQL, because any clause could be the first clause. So I'd do something like this: $and = false; // Don't use AND yet! $q = 'SELECT * FROM supplier_details'; if ($keyword) { if (!$and) { // First clause, add the WHERE: $q .= ' WHERE '; $and = true; } else { // Already had a clause $q .= ' AND '; } $q .= "supplier_name LIKE '%$keyword%'"; } You'd repeat this for the county and supplier type id, something like this: if ($county) { if (!$and) { // First clause, add the WHERE: $q .= ' WHERE '; $and = true; } else { // Already had a clause $q .= ' AND '; } $q .= "county='$county'"; } That should give you the logic you need, in only three conditionals. Remember that it relies upon validated local variables, set to false if that shouldn't be a factor in the query.

Hey Jonathon, I moved this to the "Social" forum, which I had just created last week (per Antonio Conte's suggestion). Thanks for the good question. My day starts off with ESPN, as I'm a big sports fan, then the Chicago Tribune (I grew up in Chicago, so that's where I get my news from). Then I read Failbook, to be amused. If time, I do the first three KenKen's, which are awesome (I used to do Soduko). I pretty much do all my shopping at Amazon, although I often comparison shop elsewhere (and then buy at Amazon). When I was writing the e-commerce book, I was well aware that Amazon pretty much does everything right from a user interface, e-commerce perspective.

It's funny that you say that. By the time I went from the first edition to my first book to the second, I had learned a lot about writing, and thought I had made some great improvements to the second edition. It's at that time that I realized that I do lots of things as a writer, except make sure the reader actually reads everything I write!

If you're loading the HTML form through the file system, not through a URL, then the PHP script will never be executed. This is why I stress, heavily, that you must always use HTTP://something. What URL did you use to run PHP scripts in earlier chapters?

That's very strange, because that .htaccess should work. Could you post the entire contents of your root-level .htaccess file here? Also, just so you know, just switching from MySQL Improved functions to MySQL standard functions shouldn't be a solution to problems.

If I recall, I just ran the non-stored procedure queries and the stored procedure queries in the MySQL client and compared the execution times (I did this a few times). It's not the most scientific or thorough approach, but the SP ran much faster than the stand-alone queries. And you have to factor in that the SP had logic that the stand-alone queries did not, so putting those queries into a PHP script would have been even slower, as that script would have had to execute other queries and implement more logic.

I'm glad you have a good experience with GoDaddy, but I would not recommend them. A client project was already with GoDaddy, and while they're not bad, in my experience, you can do better. I always recommend using a company that just does hosting (whereas GoDaddy's business is primarily domain registration).