Pikachu2000

Anyhow, I hope everyone has been well for the time I've been inactive. It's good to see a lot of the same names around here.

Hi Gizmo! Thanks for the input. I dumped the prefixes from the field names. You're right, they're unnecessary. I don't have any PKs that are anything other than INT and AUTOINCREMENT. With the relatively small number of records I expect and my lack of database expertise (and the fact it's been about ten years since I've attempted to do any coding, lol) I'm gonna avoid using separate tables for the category and type values. Maybe if I feel more confident as I work my way through this, I'll change my mind . . .

Thanks, Barand. Yes, I see where options would be more accurate. This is something I'm making for my own use, at least for the time being. My Cisco Systems lapsed quite a while ago, and I'm studying to take the tests again. I find that doing things like this as part of the studying process helps me retain more of the information. I suppose if I feel I've done an amazing job of it, I might offer it to others in the future. I'll structure it so adding the user related tables in the future will be possible.

The part about nulls was what I remember hearing from several people too, but I don't know enough about DB structures to agree or disagree, haha. Anyhow, this is what I've cobbled together for now. Any suggestions, or is it an OK starting point?

Ok, thank you. The reason I was thinking of a separate images table is that only about a third of the questions will have any image at all, and some may have one type, the other type or possibly even both types. I didn't want to leave a bunch of empty fields in the question table, but if that doesn't matter I'm fine with it. My thinking was along the same lines with a table for correct answers, but again if it doesn't matter, it doesn't matter. EDIT: It's also possible any one question could have an unknown number of either/both image types.

It's been a very long time since I've done much coding, and even then I wasn't a database guy (beyond being able to write a query if I needed to). I may be over complicating this, but I'm starting a small project for myself and want to use a DB for it. It will be a quiz/test engine, holding possibly as many as 4000-5000 questions. It won't likely ever be any larger than that. It will need to hold: Question ID Question Type (either multi choice 1 answer, multi choice multi answer, or drag n drop) Question Text The text for each answer option or drag n drop item (average of 4 per question) A way to denote correct answer option(s) Filesystem link to a statically displayed image, if one exists for the Q Optional filesystem link to an image that can be opened by a clickable button on the question page Possibly one or two other pieces of info that I haven't thought of yet, lol I'm thinking I need probably three or four tables. One for question text and type One for the answer text options, with a foreign key to the Question ID One for image info, with a field to denote whether it's static or buttoned with an FK to Question ID Possibly another table to hold the IDs of the correct answers with an FK to QID again? Does that sound about right, or have I completely missed the mark?

$sql = "SELECT id, category, bilde, title FROM oppskrift_table WHERE category = 'Appetizers & Beverages' ORDER BY title ";

The form field name= values look backwards to me. Just sayin' . . .

Hahaha. Yeah, I'm around again. Probably not nearly as much as I used to be, but who knows? My poor Stars didn't do so well today . . .

Look at the opening php tag for the require_once() in template.php. Notice anything missing?

If you're saying you have bar stored in a variable without the double quotes and want to echo it with quotes: $foo = 'bar'; echo '"' . $foo . '"';

The only validation you have is probably the Javascript for the form, which is pretty much useless as an actual validation method. Spambots and pretty much anyone who knows how to shut off Javascript in their browser can easily bypass it. All user input needs to be validated on the server side. Anything on the client side should be considered to be nothing more than a convenience (or inconvenience in some cases) for the user.

No. You're over-complicating it to death. Just table.field is fine, backticks should never be needed with that syntax. Your initial problem was caused by one of the AS aliases: as out, not a table or field name. Really, your best course of action would be to simply forget about the backticks and use a different field alias; one that isn't a reserved word.

I'm relatively certain you don't need backticks with this syntax: table.field, and if you did use them for whatever reason, it would be `table`.`field` rather than `table.field`

All string type user data should be escaped before being allowed anywhere near a query string. mysql_real_escape_string or mysqli_real_escape_string, depending on whether you use mysql or mysqli extension functions.