Is there a better approach?

The only good reason I can think of to use a file and delayed update if if you have really big tables and lots of indexes so the updates work better as a batch with a disable index, insert, reneable index type approach.

Why not just:

use CGI;
use DBI;
my $q = new CGI;
if ( $q->param('submit') ) {
    my ( $good_data, $errors ) = validate( $q );
    if ( $errors ) {
        show_form( $errors );
    }
    else {
        update_db( $good_data );
        my $pass = get_password();
        show_success( $pass );
    }
}
else {
    # default to show the form
    show_form();
}
exit 0;
[download]

I am very sorry. I did not explain myself very well (as evidence that 3 of you 'took' my question the same way).

Using the DBI module, won't I need to hardcode a database userid & password into my dvi script (for example, in the code above, in the 'update_db' function?

I was thinking about the colon delimited file b/c I could avoid the script having access to direcly write data to my db.

Does this explain it better? I hope so, and I am sorry for the misinterpretation.

thanks!!!

Well, if you're determined to hand-update your database by forcing yourself to manually type your db's ID and password each time, then by all means write to a delimited file first. However, that solution isn't typical; there are a number of ways to secure a database password in a CGI environment, the most common approach being putting the ID and password into a file that is outside of your web server's root directory, setting the appropriate permissions to limit access, and then 'INCLUDE'-ing or "USE"-ing the file into your CGI. It all depends on your level of paranoia.

Gary Blackburn
Trained Killer

untainting all user input is an important thing, however, if you're using DBI.pm you may want to use placeholders; there's also a section on that in the DBI docs. if you use placeholders then DBI will take care of quoting the actual data correctly; but of course it will be helpful to additionally look into the data before if it contains the format you want.

about the cronjob: why don't you want to use a DB-connection directly? only if you expect high traffic this can be a bottleneck, but then i would consider using mod_perl instead of CGI, so the db connection can be programmed persistent.