Kristina D. H. Anderson wrote: >>> But in the case of a form, wouldn't you be validating the input before >>> trying to insert the record? Sorry if I seem dense--I must be >>> misunderstanding something. > > No, you are exactly right, and you'll want to use a combination of > client-side (form) validation and good database design, and make > decisions based on the individual application. But, you also need to > be aware of other people's database design choices, and code around > them. It's good to know that a blank string is not null when you need > to populate a field that is supposed to be NOT NULL but actually has no > value to be inserted...and that sounds insane, but I've seen stuff like > this over the years, and sometimes it cannot be changed but only dealt > with. :)
Ah, okay, I see your point now. > Also sometimes you're not dealing with forms, let's say you have a web > service that's sending you XML which gets processed and goes right into > the database without your ever seeing it in the production environment > (and this is getting more and more common these days, and there is just > nobody sitting around reading a generated log of every response that > comes in to check them, like I suggested you do in a test > environment...that defeats the purpose of automatically inserting the > data!), so the best way you're able to generate an error if fields are > missing is if the query doesn't execute...this can happen, say, if the > people sending you the data change something and don't bother to notify > you...if your fields in the database will accept NULL inputs, you could > look a week later and see missing data...there are a lot of different > cases and all the solutions are different. That makes perfect sense in the situation you describe. *wonders if this programming stuff is ever going to get easier* Bev ;) _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show_participation.php
