. . . mentions the placeholder for an auto incre. id is not necessary (however, I have found in other scripts this was necessary--weird).

The node in question was correct. Not only is setting an auto increment field unnecessary, it's undesirable without a really good reason. I suspect the other scripts you mentioned were using a database with a bad schema.

$sth = $dbh->prepare (q{
   INSERT INTO sponsor VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)}
);
[download]

After you call prepare, add a or die "Couldn't prepare statement: " . $dbh->errstr;, or turn RaiseError on when you call DBI->connect (unless you already have). A similar note goes for the execute (which can fail if you have an incorrect number of parameters).

You have a huge number of placeholders there. Instead of a static SQL statement, you can generate the SQL at runtime to ensure you have the correct number of placeholders for your data. This can be done by pulling all the parameters you set out of execute statement and into a hash. The keys of the hash are the name of the fields, and the values are the data you put in for that field. Example:

my %sql_data = (
    name     => $name, 
    address  => $address, 
    # and so on
);
my $sql = q/INSERT INTO sponsor (/ . 
    join(',', keys %sql_data) . 
    q/) VALUES (/ . 
    join(',', ('?') x keys %sql_data) . 
    q/)/;
my $sth = $dbh->prepare($sql) or die $dbh->errstr;
# values() is guarenteed to come out in the same order as keys()
$sth->execute(values %sql_data) or die $dbh->errstr;
$sth->finish();
[download]