David L

Larry, thanks!! I'll implement your suggestion. I didn't do it originally because I wanted to avoid adding an extra mysql query (to grab a random user_id) to every single page load, but I guess its the better way to go.

Hey everyone, I am running into issues using header("Location: x"), as the history (back/forward) buttons in browsers don't seem to keep track properly of the redirects. It's complicated to put into words, so I made a screencast demonstrating the issue. Watch in full screen mode so you can see what I am doing. http://youtu.be/C2Fzkcp5kME If anybody has a solution, I'd be very grateful. Thanks!

Woops, typo, try: while ($ca = mysqli_fetch_array($cr, MYSQLI_ASSOC)) { echo '<option value="' . $ca['checklist_timeframe_id'] . '"'; if ($info['checklist_timeframe_id'] == $ca['checklist_timeframe_id']) { echo ' selected="selected"'; } echo '>' . $ca['checklist_timeframe'] . '</option>'; mysqli_free_result($cr);//free up resources }

Try while ($ca = mysqli_fetch_array($cr, MYSQLI_ASSOC)) { echo '<option value="' . $ca['checklist_timeframe_id'] . '"'; if ($info['checklist_timeframe_id'] ==$ca['checklist_timeframe_id']) { echo ' "selected="selected"'; } echo '>' . $ca['checklist_timeframe'] . '</option>'; mysqli_free_result($cr);//free up resources }

[color=#000000][font=monospace][size=2]echo [/size][/font][/color][color=#008800][font=monospace][size=2]'<p>'[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] mysqli_error[/size][/font][/color][color=#666600][font=monospace][size=2]([/size][/font][/color][color=#000000][font=monospace][size=2]$dbc[/size][/font][/color][color=#666600][font=monospace][size=2])[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#008800][font=monospace][size=2]'</p><p>Query: '[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] $q [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#008800][font=monospace][size=2]'</p>';[/size][/font][/color] I meant this: echo '<p>' . mysqli_error($dbc) . '</p><p>Query: ' . $q . '</p>';

When you do a password change, you are using an UPDATE query. An UPDATE query is supposed to say "change value x to value y". In your case, the old password is the same as the new. In effect you are telling mysql: Please update value x to value x. Which makes no sense. This is why mysql returns 0 Rows Affected because nothing happened and no rows were changed - as your UPDATE query doesn't make sense. mysqli_error shows no error because there was no error! Your update query is perfect valid syntactically. It just doesn't do anything because the old password and the new password are identical. But no error occurred. Side point: Please delete the line - [color=#000000][font=monospace][size=2]echo [/size][/font][/color][color=#008800][font=monospace][size=2]'<p>'[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] mysqli_error[/size][/font][/color][color=#666600][font=monospace][size=2]([/size][/font][/color][color=#000000][font=monospace][size=2]$dbc[/size][/font][/color][color=#666600][font=monospace][size=2])[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#008800][font=monospace][size=2]'</p><p>Query: '[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] $q [/size][/font][/color][color=#666600][font=monospace][size=2].[/size][/font][/color][color=#000000][font=monospace][size=2] [/size][/font][/color][color=#008800][font=monospace][size=2]'</p>';[/size][/font][/color] You really don't want to be showing your users the mysqli error details. Doing so is a significant security flaw as your user will see details pertaining to the design of your database. You never want to be

A database design question - I am posting this in the Advanced section cause I want to hear what other advanced programmers think. I am in the middle of developing a site for a client. The site has user profiles, which work exclusively via Facebook Connect: the first time a user logs in with Facebook Connect it reads his facebook info and puts it into a profile for him. Now, I am noticing that the locations given by the Facebook API are not normalized! For example: "hometown": { "id": "108363292521622", "name": "Oakland, California" }, "location": { "id": "109650795719651", "name": "Los Gatos, California" }, In a regular design of course, Los Angeles would be in a states table and the cities in a cities table with a foreign key to states. (All other data returned by Facebook API is properly split up according to normalization.) My question: While this is not ideal design, is it nonetheless OK for me to follow this style, and simply create one locations table where cities and states are stored together like FB does? While splitting cities from states from countries would be ideal, of course, keep in mind that the script which reads the FB API data and inserts it into my websites tables to create a user profile is already very database query intensive - so far it has about 10 db queries - and I would rather not exacerbate that by adding even more queries to search and find and insert cities and states and countries. And if this db design is inexcusable - why is FB doing it this way? Thoughts?

Thanks guys, I like Stuart's first solution the most, using arrays and counters seems like the best and most polished way to go for lists as equal as possible without splitting letters in the middle... Thanks so much!

This is a little difficult to explain, but I'll do my best: I am creating an event ticketing system, and am using the info in this book create a PDF-formatted check-in list of each event's attendees. Problem: An event can have hundreds of guests. The client wants the ability to divide the printed attendee list into smaller lists, so that if there are 5 staff members on hand for an event doing check-in, he will split the list into five lists and each staff member handles a list. The problem is that if the attendee list is ordered by last name and then divided into five equal sections, the lists are not alphabetically grouped. Ideally, you would want list 1 to handle all attendees with a last name beginning A B or C, list 2 with all attendees E F G H and so on. If you just divide the list into five equal sections, list 1 would have all A B C and a few D's, the next list would have the remaining Ds and then E F G and some H, list 3 has some H and I J K and so on. Which is messy. How do I divide a list into approximately x equal parts, while still keeping it alphabetically grouped?

I was using i for integer - is that incorrect?

I now see that this problem only occurs when using prepared statements. If I run a normal query without a prepared statement, like: "INSERT INTO transactions (order_id, trans_type, trans_amount, response_code, response_reason, authorize_id, response, trans_date) VALUES (100,'AUTH_CAPTURE','100',1,'This transaction has been approved.',2161546092,'response string here',NOW())" then I have no problems and the transaction id remains 2161546092. Anyone knows how to make this work with prepared statements too?

My transactions table has a authorize_id BIGINT(20) UNSIGNED NOT NULL column as specified in the book. However the ID numbers being returned by Authorize change upon the DB insert because it is being inserted as an integer. For example, Authorize ID returns transaction number 2161546092. When it is inserted into the database, it changes to 2147483647. (In PHP, doing echo intval('2161546092') also produces 2147483647). How do I stop this happening?

Side question: Is there any difference between using !== versus != Do they have do different things? Just curious.

Hi guys, Another quick normalization/database planning question: In the book, Larry re-records the price of each sale in the order_contents and orders tables (instead using a FK to the product) in case the price of the product changes in the future. My situation is somewhat different: I am working on a ticketing system. Each event ticket consists of multiple "Price Points". A Price Point says that on day x at time x the price of this ticket becomes $x. So the ticket price increases as the event becomes closer. Now Price Points cannot be edited. To overwrite a Price Point, the user creates a new one. So in my order_contents table I am simply going to use a FK to the price point purchased, since the price of that price point can never change. Simple enough. Here is my question: This company is very promo-code happy. They make upward of 50 discount codes per ticket! To keep the database nice and clean (and hopefully well normalized), which would be the smarter option? - a: Make promo codes also un-editable, and just include in the orders table a FK to the promo code used. The con is I will have thousands and thousands of codes which can never be deleted. b: Store for each order the promo code name and price used. It is a little redundant, but maybe should be done anyway (like Larry did) so I don't have to keep all those thousands of promo codes in the database for all time. (Keep in mind that I expect most promo codes to be used at least once, so I am recording lots of extra data this way.) Many thanks.

I'm working an a shopping system based on the cart and am trying to understand the consequences of the following redundancy/normalization issue: The cart will have table promo_codes with discount codes. Each discount code only works for a specific item (client's request). So each row in the table consists of : id name (like 'SALE' or whatever) amount expires (datetime) Now, thinking ahead a little, chances are the client is going to name 75% of the codes with such original names like 'SALE' 'PRESALE' and 'EARLYBIRD' At first glance this looks like a violation of 2NF, because the table has many rows with repeating data in the same column (a non-key which is not dependent on the primary key). However, upon further analyzation, it seems to me that this isn't so. The examples of violations brought in Larry's other book, PHP 6 and MySQL 5, were 'Humphrey Bogart' and 'Martin Scorsese' where the multiple instances of Martin Scorsese within the same table are referring to the same human being Martin Scorsese. Here however, the multiple instances of the code 'PRESALE' are not actually related at all, they are different codes, on different items, which just happen to share a common name. So if I understand correctly, this would not be a violation of 2NF, as each instance of 'PRESALE' is individual and thus is dependent on its primary key. However, at the end of the day, the table is still going to have 3000 instances of 'PRESALE'. In other words, it is redundant, but not a normalization violation. Does this mean the database is completely safe from data integrity problems even with 3000 (different) instances of 'PRESALE'?