HartleySan

Have you tried running a query like the following directly on the DB? INSERT INTO 20140420Attend (person_id) VALUES (199);

I just tried to go to it, and it didn't work.

Ah, okay. That's very possible, although I don't know because I've never done it. Either way, you shouldn't need GitHub to share files between computers. Git is more than sufficient.

Not that I know of, no.

Yes, Git is the default version control system these days, so learning to use it is very beneficial.

What does your POST array look like? Have you tried running the queries directly on the DB to see what happens?

If the line isn't already uncommented after installing PHP, then yes, you need to uncomment that line to use PHP with your Apache installation. That is the main line in your Apache config file that enables PHP. This might help: http://stackoverflow.com/questions/69768/how-do-you-configure-the-apache-server-which-ships-mac-os-x

This article may prove of use: http://www.makeuseof.com/tag/how-to-easily-share-files-across-mac-windows-computers/

Glad I could help. Good luck.

Add selected="selected" to the appropriate option.

Hello and welcome to the forums. mod_rewrite is a tricky thing that causes a lot of people problems. For testing purposes, start of with something very simple (e.g., RewriteRule a.html b.html), and make sure that works. If it does, then you know the problem is with your regexes. If it doesn't, then you know the problem is with your setup/configuration.

There are two ways to add null via a prepared statement: Dynamically generate the query, and add NULL as necessary; or Assign null to a variable, and then bind the variable. For example, your query could be: $query = "UPDATE pages SET cat_p_id = ?, tag_p_id = ?, user_id = ?, status = ?, title = ?, summary = ?, ingredient = ?, recipe = ?, tips = ?, filename = NULL, date_updated = NOW() WHERE page_id = $page_id;"; Or, you could set up the $file_name variable as follows: $file_name = $file_name ? $file_name : null; That make sense? As a side note, you may want to use a question mark for page_id as well, if $page_id is user-provided.

Hello and welcome to the forums, surow. You sure you got the scripts for the right book and right edition of the book?

This of any help? http://jason.pureconcepts.net/2012/10/install-apache-php-mysql-mac-os-x/

Could you please elaborate on what you mean by wanting to place content in multiple categories? How would you like to add the categories to content, and how would you like the content to be searchable/viewable?

I don't think it's a percentage thing so much as a what-does-the-scenario-call-for thing. Switch statements are generally preferable when you have a bunch of string or number values that a variable can be, and you want to switch up the behavior based on what the current value is. If statements are generally more for making complex comparisons that aren't simply, "Is this variable equal to this value?" As a side note, an array or object (i.e., hash table) can often be used as a more efficient replacement of a switch statement. Please Google it for more details.

I know this isn't the case, but let's say that hypothetically the combination of m_id and type were always unique. That being the case, you can set up a unique index that spans those two columns (please see the documentation for how to create multicolumn indexes), and then you're SELECT queries would be like the following: SELECT * FROM listings WHERE m_id = ? AND type = ?; That make sense? With that said, if you know the l_id, which is the primary key, that will always be a quicker select because it's the primary key and essentially just a key-value lookup, but depending on how the table data is used in relation to other tables/data, the multicolumn index without the l_id column might make more sense.

You're right that m_id by itself is not unique, but like I said, if m_id in combination with one or more other columns is unique, then you don't need the l_id.

That looks good, Cofa. My one comment is that for the listings table, if m_id combined with one or more other columns in the table is always unique, you can set that as your unique index, and probably get rid of the l_id column. With that said though, depending on how you're accessing the data, the l_id column could be beneficial. Well, if it works for ya, no complaints.

Glad I could be of assistance. Please keep up the good work yourself!

Yes, it is a unique index, and there is no primary key. Also, my query is doing a join across three tables, although it may not be very obvious. The syntax I used is an abbreviated way of performing an inner join across three tables.

Your design is correct, but you are incorrect in that duplicate keys will be created. For example, let's imagine the following users and courses tables: users 1 Bill 2 Pam 3 Steve courses 1 Intro to Web Development 2 Advanced Web Development 3 Basket Weaving 4 Basketball Now, let's say that Bill wants to take both Intro to Web Development and Basketball. Then we'd enter the following two entries into the users_courses table (where the first number is the user ID and the second is the course ID): 1 1 1 4 Even though the user ID is the same, because the combinations of the user ID and course ID are unique, we're fine. In other words, DB integrity has been preserved. With the above design (i.e., your design), you could then run the following query to get all courses that Bill is taking: SELECT course_name FROM courses, users_courses, users WHERE courses.course_id = users_courses.course_id AND users_courses.user_id = users.user_id AND users.user_id = 1; Really, the important thing to note is that user_id by itself cannot be a primary key for the users_courses table. The "key" is to make a multicolumn key, which is very common. That make sense?

There's obviously something funky going on, so I think that further digging is required. As a first step, I'd turn error handling on, and then start echoing lots of info to the screen to try and discover what is wrong. I'd also start executing queries directly on the DB (as opposed through PHP), and see if you can find anything that way.

Your code looks pretty solid, but you should note that your $rowcount > 1 condition will let things slip through when there's one entry in the DB. You should do > 0 or >= 1.

Have you tried mysqli_num_rows to check the number of rows returned from the DB?