HartleySan

Awesome. Learned something myself, as I sometimes use Japanese.

I think I see what you're trying to say. You want to have an HTML table of data from a database that's organized, and when you click an "Edit" button next to an entry, another page is loaded with all the corresponding info loaded into a form for editing, right? Assuming that's what you're talking about, Larry addresses that exact thing in his PHP 6 & MySQL 5 book. He has a whole part about editing existing users, and it's pretty much like you're suggesting: Post the ID to a script for editing, which uses that ID to load the proper data into a form, and when the form is submitted all the values are checked for validity and the corresponding database entries are updated. Anyway, muuucho, to fully answer your question, you don't really need to add a function for this, because you'll want to call a separate script, which will handle any ID all the same, and since you only need to write the code once, a function isn't necessary. Does that answer your question?

It took me a while (sorry, was a bit slow-headed about this one), but I finally realized what was going on. It's exactly as Matt stated in his example from PHP.net above. As for a solution, well, I think there are many, but I'm more and more leaning toward an entire restructing of Matt's site (much to his chagrin). Certainly, Larry, if you want to share your opinions, we'd like to hear them, but I'm realizing more and more that this issue (among many other potential ones) can be easily resolved but simplifying and restructing Matt's site a bit. I'll talk with him more later, and see what he thinks. In the meantime, please share your opinions, Larry. Thanks.

bahaa, I have never sent non-English subjects via the mail function, and I don't have any means with which to test out anything at the moment, but I would recommend consulting the page about the mail function on PHP.net (http://php.net/manual/en/function.mail.php). While quickly scanning through, I found the following: Italian users cursing against "È" and other uppercase-accented-vowels ("vocali maiuscole accentate"") in subjects! While the lowercase ones ("è", "é" and so on) work as expected, qmail doesn't handle the uppercase ones. To fix it, the only way I found was this: <?php function mail_utf8($to, $subject = '(No subject)', $message = '', $header = '') { $header_ = 'MIME-Version: 1.0' . "\r\n" . 'Content-type: text/plain; charset=UTF-8' . "\r\n"; mail($to, '=?UTF-8?B?'.base64_encode($subject).'?=', $message, $header_ . $header); } ?> It should apply to other languages too. It definitely seems like this is an issue with header information and the wrong encoding being used. And here is one more decent link for good measure: http://bytes.com/topic/php/answers/745913-how-send-subject-chinese-using-mail Please try these out, and then let us know if it works. Edit: Dangit, Larry! You gotta stop writing the answer in at the same time I do, and then beat me to the punch in actually posting your answer.

Ron, there are a few things to consider here. First and foremost though, it's important to understand what this is referring to in the following line: <select name='seasonid' onchange="window.location.href=reports.php?season=this.form.seasonid.options[this.form.seasonid.selectedIndex].value"> Before I tell you what it's referring to, I want you to think about it a bit. Maybe even do a little research if necessary. You got it? this is referring to the select HTML element that the JS is being invoked in. As such, this does not have a form property, a seasonid property, etc., etc. Basically, I'm surprised your browser is not spitting out JS errors left and right. You might want to try loading your page with a JS debugger and seeing what kind of error messages you get. Anyway, to make a long story short, because this refers to the select HTML element (essentially, the select tag), to get the value of the selected option, you need only use this.value. Using your code as a base, I've created the following simple script to illustrate my point. Feel free to copy and paste it into a blank HTML file and run it in your browser. Select a drop-down list item, and see the results. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>onchange event test</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <form method='post' action='reporthandler.php'> <select name='seasonid'> <option value=2>2011-2012</option> <option value=1>2010-2011</option> </select> </form> <script type="text/javascript"> document.getElementById('seasonid').onchange = function() { alert(this.value); }; //document.forms[0].seasonid.onchange = function() { alert(this.value); }; This is also valid, and returns the same thing. </script> </body> </html> The main thing to note is that by simply using this.value (and the JS alert function to report that value to the screen), we can very easily see that we have access to the values. The other thing I want to note is the separation of code. Really, you should not mix JavaScript with HTML by placing JS in inline tags. Instead, do what I'm doing and access the HTML element you want via the DOM, attach the onchange event to it, and then do what you have to do within the anonymous function. You could also call another function from here, if need be. The last thing I want to mention is that even if you use your method, you're still going to have to reload the page after the user makes a selection. Instead (if you want to make things smooth), I highly recommend using Ajax to make an asynchronous call to a PHP script/database and return the data without having to reload the page. Anyway, I'm curious to hear your thoughts. Hope this helps.

Larry's the king for a reason, yo!

Jonathon, thanks for that info. Actually, I don't have Larry's PHP 5 Advanced book, but maybe I should get it. I have his PHP 6 & MySQL 5 book, and also a few others. Anyway, from what I had read, he had never put a script in an image tag, so I assumed he didn't approve of it either. Regardless, I would be curious to hear what Larry has to say. Also, tony, good find in that SESSION article. I didn't actually read the whole thing, but I figured that some pertinent info had to be in there somewhere. I guess we all learned something with this topic. Thanks.

Hehe! Well, I guarantee Matt does, but I'm going to refuse on both of our behalves for the time being. The fact of the matter is that we have the site working, albeit not in the best fashion. In the meantime, Matt's gonna continue developing the site, and when I get the time (which is hard to find these days), I'm gonna look very carefully at his code, study more about global in PHP, and try to find the best solution. We'll get back with you, Larry. As always, we appreciate all the help and support, but please give us a bit longer. Thanks.

tony, at the very least, you might want to consider using a PHP script to automatically create varying sizes for each of the images, and storing them all on your server. Naturally, that means more server space being occupied, but it also means significantly faster load times (which I consider a fair trade-off). As for wanting the images outside the web root, well, okay. It seems like a lot of unnecessary headaches to protect some information that seems unnecessary to protect, but then again, I'm not aware of the nature of your site. Anyway, I looked into it a bit more thoroughly, and while (according to the W3C) scripts are not valid values for the src attribute, it obviously works, and is pretty much the only way to do what you want to do. Well, good luck with that all. I think at this point, you have enough to go on. You still might want to try reading more about the $_SESSION superglobal. Here's a link to get you started: http://www.php.net/manual/en/book.session.php

It's hard to answer the question beyond just "I don't like it." However, I did a little research and found the following: According to the W3C specs for img tags in HTML 4.01 (and I imagine HTML5 is the same), the src attribute is used as follows: src = uri [CT] This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG. (Source: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.2) So that right there tells me that (even if they are usable) PHP scripts should not be referenced from a src attribute. Also, I found the following on the W3C wiki: src = URL potentially surrounded by spaces Specifies a URL referencing a non-interactive, optionally animated, image that is neither paged nor scripted. Again, "image" to me does not mean "PHP script". As we all know, HTML let's us get away with a lot of things that we shouldn't do. Also, looking at the XHTML specs, I don't see anything indicating anything different. Furthermore, if you want to display images via a PHP script, there just seem like so many other (easier) ways. For example, writing and calling a function that outputs an image to the screen, or simply doing something like the following: <?php ... <img src="' . $imagePath . '"> ... ?> I mean, really, is it that hard? The one exception would be images not in the web root, I suppose, but again, that is not really relevant to this discussion. Well, that's just my two cents. Admittedly, I'm kinda trying to just find a reason because you asked, but something tells me it's odd, regardless.

I agree. After retrieving the info once, it's better to keep it in a session variable then recall it from the database.

I seem to recall Larry talking about this in his PHP 6 & MySQL 5 book. I think you use the header function with 'Location: ' to tell the PHP script where to go to next. After logging the user out, you could probably very easily just direct the user back to the index.php script, and the user wouldn't even notice. Of course, if it were me, I think I would want to be redirected to the main page after consciously choosing to log out, regardless of what page I logged out from. Anyway, that's just me.

As usual, Paul comes in with a stunning answer. Thanks, Paul. And certainly, using a test like that would eliminate the need for JS. If you go that route though, I'd definitely put a note next to the State field telling the user that they only need to enter a state if the country is the US. Better yet, you might want to make a drop-down list with all the states. That seems more intuitive for users. Also, you could set the default value for the drop-down list to something like --. I think that's pretty straightforward. If you decide to go the JS route, you'll need to attach an event to the Country field to basically detect when info is entered for the Country field, and when it is, test whether it's some variation on the US (this can be tricky, and will probably require a regex), and if the country is the US, you'll need to use DHTML to dynamically insert a div with the State field below the Country field. Not incredibly difficult, but not for beginners of JS either. Anyway, I think Paul's suggestion would be easier with a little note next to the State field. Also, a drop-down list for the states (and countries) would be best, I think.

I have a feeling that something is going on with your $_SESSION superglobal. This actually sounds quite similar to an issue in JavaScript related to closure. Anyway, you're probably going to have to look into the innerworkings of $_SESSION, and see exactly what's going on behind the scenes, or you could try using the GET method instead. For example, you could change the following line as follows: echo '<img src="_a_makePicByWidth.php" />' ; echo '<img src="_a_makePicByWidth.php?picName=ronald_mcdonald.jpg" />'; And then you could retrieve that info in the PHP script as follows: $picName = $_GET['picName']; Naturally, you'd have to add the info for the width as well. Anyway, that's just one possible solution. To be honest, there are two things I would recommend not doing: 1) Not using $_SESSION for this kind of thing. 2) While you can call a PHP script for img src, I wouldn't recommend it. Maybe it's totally kosher, but something about it really bugs me. Well, hope that helps out a little.

Larry, not to butt in, but actually, if you don't mind, I think Matt and I can figure this one out. I haven't had enough time to look at his code personally, and the truth is, it's rather complex, and not easy to explain on this forum. As such, please give us a little more time to look into it first. Hopefully, we can find a good answer, and post it here. Matt, sorry for that. We'll find a good solution though. Please be patient.

I'm not familiar with record sets in Dreamweaver, but I think I can respond to your other questions. First off, if you want to make a State field appear only when the US is selected for the Country field, then you're going to need to use some JavaScript. How familiar are you with JavaScript? If you want, I will gladly help you accomplish what you want to, but please first tell me how much JavaScript you know, and also exactly what you want to accomplish with this. Likewise, if you want to make the error display more "gracefully", you should probably use sticky forms (discussed in the book), and place a little message in red or something next to the State field asking them to please enter a state. Hopefully that somewhat answers your questions. Please let us know if you have any other questions.

Well, we all have different ways of understanding things, but I read Matt's post and understood it. I agree that he didn't spell it out 100% for your specific example, but all the information was there. His explanation of the Cartesian products was right on the money, and is exactly what you are experiencing. Anyway, I'm not here to accuse or defend any one person, but I do think you were a little out of line to tell Matt he's wrong, when he was anything but. Also, these boards are a privilege, not a right, and I think it goes without saying that (just like anything else in life), if you have a bad attitude, people are less likely to help. Perhaps that wasn't your intention, but from my perspective at least, in reading your post and the wording you used, you did sound upset and were rather rude. There's a difference between saying someone is "wrong", and disagreeing with them/asking them for further clarification. I'm sure Matt would have continued to help you out as best as possible to get to the answer you were looking for. And as the book states on the back cover, this is not a beginner's book, which means that there is a lot less hand-holding and examples. The Internet is full of lots of great examples about how joins operate. Please don't make me Google the information for you, just to prove how easily it can be obtained. And, of course, there's no replacement for good ol' practice and self discovery. If you had played around with the SQL queries some more and combined that with some online resources, you probably would have figured out what was going on. The way you made your posts though, it really seemed like you made no effort to take the time to very carefully consider what was being said by everyone before quickly posting a rude response. All said and done, let's just call it water under the bridge, eh? In the future, we will all try to help you, but as my mom always used to say, "You get more flies with honey than vinegar."

MikeMikeMike, I literally reiterated the same thing in your other post just now. It looks like Larry and I answered your question at the same time. Also, Matt was right all along. Larry, you ever consider bumping Matt's status up for two classy answers in a row in the face of adversity?

MikeMikeMike, I think both Matt and Larry have done a good job of explaining things to you, but I also realize that the questions they're answering are not the ones you are asking (or at least, I think that's the case). Please let me clarify. What you're saying is that the following SQL query results 10 non-duplicated results, right? SELECT gc.description, gc.image, CONCAT( "C", sc.id ) AS sku, CONCAT_WS( "-", s.size, sc.caf_decaf, sc.ground_whole, sc.price ) AS name, sc.stock FROM specific_coffees AS sc INNER JOIN sizes AS s ON s.id = sc.size_id INNER JOIN general_coffees AS gc ON gc.id = sc.general_coffee_id WHERE general_coffee_id =3 AND stock >0 ORDER BY name ASC LIMIT 0 , 30 However, if you remove the ON s.id = sc.size_id part, then you end up with 30 duplicate results, and the following query, right? SELECT gc.description, gc.image, CONCAT( "C", sc.id ) AS sku, CONCAT_WS( "-", s.size, sc.caf_decaf, sc.ground_whole, sc.price ) AS name, sc.stock FROM specific_coffees AS sc INNER JOIN sizes AS s INNER JOIN general_coffees AS gc ON gc.id = sc.general_coffee_id WHERE general_coffee_id =3 AND stock >0 ORDER BY name ASC LIMIT 0 , 30 And your question is why, right? As far as I can tell, the second query (without the ON s.id = sc.size_id part) is not a valid query. If you boil it down to the bare essentials, you have the following: SELECT stuff FROM tableA INNERJOIN tableB (more inner joins) However, this is not valid. I think what is happening is the the SQL query parser (most likely the one in phpMyAdmin) is attempting to make sense of your query, but since it doesn't know what to join on, it's joining on all possible permutations, thus giving you duplicate results. Actually, the truth is, I don't know the answer to your question, but it's an interesting question, and if I can find some time this evening, I will look into it more thoroughly and try to find you an answer. I do suspect though that the issue is with the fact that you're not supposed to omit the ON clause in the query. Edit: You're also getting 30 results, because you've limited the results to 30 via your query. In truth, there may be even more results. You may want to try removing the LIMIT clause from your query, and seeing how many results there really are. Edit #2: Both Larry and Matt are right as well. Indexes (keys) do NOT affect your results. They affect the speed with which the query can return results. Really, you should read the section in the MySQL manual about keys (as both Larry and I suggested). Foreign keys are used to help speed the database up in retrieving join results across multiple tables.

Sorry, as I don't have the book handy at the moment, but generally, you don't put actual images in a database, as they're too big, but instead provide a path to the image, etc. By using the path, you can quickly and easily load the actual image, as necessary.

Keys basically allow you to more quickly search on a given column. I hear that it's best to create keys for columns that are commonly searched through. Of course, there is a tradeoff to having too many keys (performance-wise), so I suppose the art is having just the right amount of keys in the right columns. Sorry I can't be more helpful, but I really don't know. If you do some Googling and check out the article about keys on the MySQL home page, I think you'll have more than enough information.

Indeed, just like CSS, a separate file would be best. For one, JS and CSS files are automatically cached, and assuming they're not changed, they will never have to be reloaded once someone has visited your page. Also, keeping the files separate really helps separate everything, and keeps it easy to differentiate between your structure (HTML), presentation (CSS) and functionality (JS). I usually post JS queries in the Ajax forum, as Ajax is somewhat related (but the board is far less frequented). The truth is, if you want a quick answer, this is probably the best board to post on.

My guess would be that either (for some reason) the DB connection has not yet been established, or the established DB connection stored in $dbc is not right; probably an incorrect argument in the mysqli_connect function. Are you sure you DB connection is working properly elsewhere? Sorry for the dumb comments, but I can't imagine anything else without seeing the actual code, but I also can't imagine you would want to show your DB credentials to us.

Also, check this out: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Larry's exactly right. Your form is not called form1. It's called fabric_enquiry_curtains. Change the line Larry mentioned to the following: var drop = document.fabric_enquiry_curtains.drop; It'll work then. You can also use the following: var drop = document.forms[0].drop; For more info on forms in JS, see the following: http://www.quirksmode.org/js/forms.html By the way, both Firefox and Chrome have awesome JS debuggers. FF's is called Firebug, and you need to install it as a separate extension. I actually prefer Chrome's anyway, but they're both awesome. As a note to Larry, why don't you start a JS forum of some type? I know you don't have any JS books (yet), but I think a lot of people have questions about JS, so we need somewhere to go. Also, Paul, whenever possible, try to separate your JS from your HTML. It's not a good idea to call JS functions from inline HTML tags. You might want to consider something like the following: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Fabric quantity enquiry</title> </head> <body> <h1>Fabric Quantity Enquiry</h1> <h2>Curtains</h2> <form name="fabric_enquiry_curtains"> <p>Drop (cm): <input name="drop" type="text" size="10" maxlength="10" /></p> </form> <script type="text/javascript"> var drop = document.forms[0].drop; drop.onblur = drop_onblur; function drop_onblur() { if (isNaN(drop.value) == true) { alert("Please enter a valid number"); drop.focus(); } } </script> </body> </html> Please notice a couple of things: 1) The JS is after the HTML. This is a good thing. It's faster for loading pages, and it gives the JS DOM full access to the page. 2) It separates your structure (HTML) from your functionality (JS). This is also good, as it makes it easier to read and edit code. Also, you don't need the inline function call anymore. Well, hope that helps.