cpd

The minute you move to a different site you can't alter the session which should still be active for your site. You could use frames to access these other pages through your website as some other sites do. If your just interested in knowing if they submitted a report/review regarding your site perhaps look into API's for the websites. They may have something...

I can't even find the phrase "Your invalid company description was". Are you sure this is your error? Moreover, you need to rethink your password validation as it prevents people from using common characters found in passwords...

Alter your get_all_subjects with the following. function get_all_subjects() { global $connection; //put the query into a variable. $query = "SELECT * FROM subjects ORDER By position ASC"; $subject_set = mysql_query($query, $connection); confirm_query($subject_set); $subjects = array(); while($subjects[] = mysql_fetch_assoc($subject_set)); return $subjects; } That'll return an array of your "subjects".

So your looking at reading the reports from different websites?

I'm gonna go ahead and assume you've taken this query from somewhere else then because you should be able to add another parameter to your query seeming as you've done it for all the others... And creata was right, your insert query structure is incorrect. Review what creata has said.

If your looking at normalising your database you should separate state and city as the state can be derived from the city, unless you've already done that? When they select a state just filter for all the cities by that state and order it alphabetically with the ORDER BY syntax.

If your trying to create a list of something just pull all the relevant data and then manipulate it in PHP.

From the look of it your completely miss-using the LIMIT statement. If you want to get a specific website page name you should use a WHERE clause. If you want to select all the website page names and cycle through each one you can use the DISTINCT function and then cycle through your result set.... Running the same query 80 times is absolutely obscene!

The way in which data is entered into a database is not particularly important provided each row can be identified independently with a primary key. If you want to order something alphabetically you should use the "ORDER BY" syntax in your SQL statement. Ordering by the village name in an ascending order with the "ASC" syntax will give you the statements in an alphabetical order starting with A; "DESC" will obviously reverse this. Don't get hung up on the order in which your data appears on your screen when you haven't ordered it. Doing this will cause serious aggravation when dealing with 10,000 rows or even worse a million.

It's entirely up to you. That's how I would do it and that's how many people who understand normalisation would do it, or so I'd hope. That said, please don't think its wrong to create an `id` column. Its only wrong to think this is required in every single table and some people use it as a "quick method" of creating and linking tables; I would argue that's bad practice though.

Yes sorry I see what you're saying. To make a field a key you must first index it. Apologies I did misinterpret you slightly.

Correct.

In your situation, if you were going to have a single user entering an answer for the same question more than once thus creating two rows with the same member_id and question_id, you would not be able to use them as the PK, creating a composite key from them wont really achieve anything either. However, your situation is that a single user will only be able to answer a single question once. In this situation you will only ever have a single row with a member_id and question_id. Therefore, they can be combined to create a composite key and this composite key used as the primary key. I can explain further via voice on skype if you like. Drop me a PM if you'd prefer that as it can be difficult to get across in text.

You haven't actually added Alliance to your query. You've added it as a parameter but not to the query. In future use a try statement and catch the exception where you can echo it out. try { $stmt->execute(PARAMS); } catch(PDOException $e){ echo $e->getMessage(); }

It's because your overwriting your $tables variable with the first line after your while line. The correction would be as follows $tables = ""; while(DO STUFF){ $tables .= "<tr>"; $tables .= "<td> {$row['specifiedrow']} </td>"; $tables .= "</tr>"; } also if your using PHP 5.4, or 5.3< with "short open tags" on, you can just do <?=$tables;?>

Your code will create a massive string assigned to the $thumbnails variable. You can't cycle through a string with a foreach statement. I think what your talking about, I think... foreach(range(1,10000) as $int){ // DO SOMETHING }

The server will only run as well as it can on the hardware its provided with (obviously this can be tweaked with settings but you get my general drift). There shouldn't be a reason why Apache doesn't run on Windows as well as Linux. A Windows Server should be just as capable.

Re-read my post and try doing a bit of debugging as described.

Indexes are directly related to their tables. If you index something on one table, it wont index that field on another table, you will need to do it yourself.

To add your constraints you need to run some sql along the lines of ALTER TABLE `bio_answer` ADD CONSTRAINT FOREIGN KEY (`member_id`) REFERENCES member(`id`) ON UPDATE NO ACTION ON DELETE NO ACTION, FOREIGN KEY (`question_id`) REFERENCES bio_question(`id`) ON UPDATE NO ACTION ON DELETE NO ACTION I think that's pretty much correct.

If someone makes a statement along the lines of "you need a column called ID in every table which auto increments" they are wrong. You do not need an ID column for every table. The definition of primary key is a single or set of columns which uniquely identifies a row within a table. For example, the PK for a system which maintains "Courses" can be "CourseNo" with values such as "B745A", "B746A", "B182S" etc. There is no requirement to have an auto incrementing integer as your primary key. Moreover, you can have FK's which make up PK's. That again has nothing wrong with it. A good example of this is a library database. You have a table containing the books which includes the author's and genre's. To properly normalise your database you require a many-to-many relationship between the authors and books as well as the genre's and books as each book can have more than one, of each. The "resolution table" can consist of two fields, "bookID" and "authorID" which together form a composite key and also, the primary key. This means the table has only two fields, both of which make up the PK, FK's and together a composite key.

And you should not use an auto-incrementing PK to do what awjudd is suggesting! Just in-case you were considering it.

Is it your own database?

Your primary key can be a composite key comprised of two foreign keys, there's nothing wrong with that at all as the primary key should evaluate to the two foreign keys concatenated. In some instances, this is not practical as someone may be able to answer the same question more than once, e.g. they can retake the test. However, in the situation they are only allowed to the test once, the member_id and question_id can create a composite key and be used as the primary key. My advice is evaluate the requirements and see what's best. Another field just for a primary key is not always necessary if two other fields can be put together to make a composite key.

Your code errors because, as pointed out, you have no item_id being POSTED to the header upon form submission. $row['item_id'] is not printing anything as the page is outputted. If you show us your query that gets this we can go from there.