I think you're checking the user input at the wrong point if you're relying on the DBI::errstr to tell you that user input is invalid.

From a security and usability stand point you should test your data long before you try and dump it into the database. I think the security part stands on it's own without further explanation.

The earlier you detect a problem the easier it tends to be to deal with it. What if this program routinely took 10 or 15 minutes to get to the point where the insert happens and DBI::errstr is populated? Your users will be upset.

Better options for detecting and reporting errors in web apps (in order of increasing ease of user interaction):

• Check the format with a Javascript and pop up an alert box with the error message "Format for the DATE must be YYYY-MM-DD" Then use the javascript to set the focus to the appropriate form field (provided the browser supports it and is turned on yada yada)
• Build your web form so that it is impossible for the user to enter the incorrect date. This is easier on you as a programmer and easier on your users. Use 3 select boxes: one for the year, one for the month and one for the day.

     Year     Month       Day
     [2000|v] [January|v] [26|v]
     

  (bad ascii rendering as form and table tags are filtered) You get back three values that you know are acceptable and can be concatenated into a good looking date.

    $date = $param{year} . "-" . $param{month} . "-"  . $param{day};
  [download]

  Now that format is covered (and users aren't frustrated) use a module like Date::Manip to check if a date is _valid_ (i.e. not 2000-02-31 aka Feb 31st)

(I actually skipped one option, but it relies on your application using a really good templating system and being one cgi with a lot of conditionally generated html: It's process the page on the server and return it with the offending fields highlighted and the error message above or below the field explaining the problem. The top of the page should declare that there is a problem and to pay attention to the indicators yadda yadda yadda.)

If you continue down the road you're on now are you really prepared to grep DBI::errstr for every partial error string that could be tossed from within the database?

--
Clayton

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.