Pikachu2000
-
Posts
11,377 -
Joined
-
Last visited
-
Days Won
11
Posts posted by Pikachu2000
-
-
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.
-
26 minutes ago, requinix said:
I've heard opinions that if a piece of data (read: column) will often be null then it should be moved into its own table. I don't agree.
Ah, then that means a one-to-many relationship and you're forced into creating that third table.
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' . . .
-
Holy crap a Pika sighting. Must be because the Stars evened the series yesterday. I thought they were toast after that tire fire of a first period, but they hung around.
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?
-
1
-
-
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 . '"';
-
1
-
-
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.
-
'quotes' and `backticks`
-
Kicken linked the manual page. Did you even bother to look at it?
-
If phpinfo shows it as off you should be good to go. What are the current symptoms and updated code?
-
With the code indented and formatted a bit better, it's much easier to see where these problems are:
<?php if (isset($_GET['success']) && empty ($_GET['success'])) { echo'You\'ve been registered successfully! Please check your email to activate your account'; } else { if(empty($_POST)=== false && empty($errors) === true) { $register_data = array( 'username' =>$_POST['username]'], 'password' =>$_POST['password]'], 'first_name' =>$_POST['first_name'], 'last_name' =>$_POST['last_name]'], 'email' =>$_POST['email]'], 'email_code' =>md5($_POST['username']+ microtime()) ); register_user($register_data); header('Location: register.php? success'); exit(); } else { if (empty($errors) === false) { echo output_errors($errors); } } ?> -
EDIT: The same thing Jessica said follows, but in a long-winded format : )
Using the .= (concatenation) operator appends a value to an already initialized variable. The = (assignment) operator initializes the variable and assigns a value to it. Since register_globals was silently initializing variables with names that correspond to the form field names without your knowledge, your .= operation was concatenating the same value to it again.
So to initialize and assign a value to a variable, use the = operator . . .
And if you're able to do so, restart Apache so the changes to php.ini take effect immediately.
-
Post your current code.
-
[edit] Ooh, nicely done Pikachu.
Why, thank you kind sir.
-
And even though your syntax to assign the values from the $_POST array to the variables is wrong, in this case it's what actually exposed the fact that register_globals is on. If you don't have access to your php.ini file, contact your host and request that it be turned off. If they won't, find a new host.
-
Turn off register_globals in your php.ini file. Why a host would have that enabled by default in 5.3 is beyond me.
-
Have you taken care of this? It will never work until you do.
Your <select> field needs a name= attribute, which you would then use to get the value of the <option> from the $_POST array, validate it, and use that value in the delete query.
Structure/Normalization questions
in MySQL Help
Posted
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.