Greetings all,
Although your Can't call method 'prepare' on an undefined value at... Error indicates to me that it is a problem with your $dbh not being initialized (perhaps post more code so we can see), I would also like to mention that you can alter your INSERT statement to see if it is in fact your SQL.
Rather than:
INSERT INTO sponsor VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
You could also do:
INSERT INTO sponsor(name, address, city, state, zip, country, contact,
+ title, phone, bestime, email, license, type, capacity, distributor)
+VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
This way you can map in the values you want to insert and you don't have to worry about AUTO_INCREMENT or TIMESTAMP fields since anything not specified in the field names list will get the default value from the databases column definitions. As well you can also do (update: at least in MySQL although its not standard SQL):
INSERT INTO sponsor SET name=?, address=?, city=?, state=?, zip=?, country=?, contact=?, title=?, phone=?, bestime=?, email=?, license=?, type=?, capacity=?, distributor=?
Which again allows you to specify which columns you want to insert and columns not specified get default values.
Just some other approaches to your insert.
However back to your error I would check that your $dbh is being successfully initialized.
my $dbh = DBI->connect('DBI:yourdb_driver:your_dbname','user','passwor
+d') || die $DBI::errstr;
Should do it.
side note: I have also seen people set AUTO_INCREMENT columns to 'NULL' to get values back... just a thought.
Hope that helps
| [reply]
[d/l]
[select] |
I would avoid the insert ... set foo = ?, ... syntax, as it is completely non-standard SQL.
Michael
| [reply]
[d/l] |
| [reply] |
| [reply]
[d/l]
[select] |
Most likely, your prepare fails. But you aren't testing for
it, let alone are you inspecting a possible error message.
Abigail | [reply] |
| [reply]
[d/l]
[select] |
. . . 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(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)}
);
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();
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
On a note of maintinability/style.. it's better to use complete inserts i.e.
INSERT INTO tablex (field1, field2, field3) VALUES ('x','y','z')
over incomplete inserts i.e.
INSERT INTO tablex('x','y','z')
Performing the following:
ALTER TABLE tablex ADD field4 varchar(20)
breaks your incomplete insert, since you are not specifying directly which fields the values being inserted are mapped to, it expects your insert to include a value for field4.
If you have an app that uses this table but will never make use of the new field: field4, then you have no need to alter that app. Leaving incomplete inserts lying around in a script is a recipe for disaster.
p.s. I learned this the hard way.
| [reply]
[d/l]
[select] |
| [reply] |
Abigail-II already answered you should check the error values from you calls.
But to answer your other questions.
An autoincrement can be either NULL, 0 or left out all of which gives the desired value. If you give a specific value it will use that.
TIMESTAMP is similar. (I may be wrong about the value '0', though)
| [reply]
[d/l] |