I don't see you issuing a disconnect, so perhaps it's possible to reuse $dbh, and avoid reconnecting from within print_form.
That should AFAIK be correct, as long as it is one Db then issuing the connect() command once is sufficient for multiple queries.
As for the error info try something like:
my $dbh = DBI->connect ("DBI:${dbtype}:${dbname}", "$dbuser", "$dbpass
+") || die $DBI::errstr;
This will give you more detail as 'to what is going on'. | [reply]
[d/l] |
my $dbh = DBI->connect(
"DBI:${dbtype}:${dbname}", $dbuser, $dbpass),
{RaiseError => 1},
);
# oops!
$dbh->prepare('slecet foo from baz');
Now every database method will raise an error automatically
if one is encountered - Laziness! And get out of the habit of putting quotes around variables
when you don't need to.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply]
[d/l] |
G'day jeffa
I'll certainly take this on board, but why is this ?
"And get out of the habit of putting quotes around variables when you don't need to."
Cheers
lagrenouille
| [reply] |
G'day dws
Cheers for editing the post as well, looks better thanks.
1. ok, will investigate thanks, I noticed when I first started the error passed to the logs was of a different format, however it still die'ed appropriately.
2. As for 1
3. Yeah, I thought so too and added the extra connect line in an attempt to get it to read out the variables... (sorry should have removed it before posting)
4. Why is this ? If I were to enable carp(fatalsToBrowsers) then obviously a content type header is required first... or is it just to make sure something is printed if the script dies ? I have an error handling subroutine, which prints headers...
5. I was initially using them, but prefered the output I could generate with raw print commands... I guess it's what you're used to... any immediate advantages, CGI.pm over raw HTML ?
6. Ah yes, yes I was, I found that soon after I posted that and still no joy... the script still fails to print any of the variables when requested, meaning they were not correctly retrieved from the mySQL database, something I am able to do by copying and pasting commands from the script into shell based mySQL...
7. I know, to some extent that's just because this script is for a very specific situation, the other reason is, I've just taken it back to step 1 in an attempt to get the mySQL retrieval working...
Cheers once again
lagrenouille | [reply] |
4. Why is this ? If I were to enable carp(fatalsToBrowsers) then obviously a content type header is required first... or is it just to make sure something is printed if the script dies ? I have an error handling subroutine, which prints headers...
As long as you have a guaranteed way of getting a content type header out first, you're O.K.
5. I was initially using [CGI methods to emit HTML], but prefered the output I could generate with raw print commands... I guess it's what you're used to... any immediate advantages, CGI.pm over raw HTML ?
If templating is overkill for you, and if you can emit code by hand that suites your needs, then do so. Some people find that using CGI methods makes it easier to generate correct HTML. If you're going to stick this hand-generated HTML, consider carefully the snippet that jeffa provides elsewhere in this thread.
| [reply] |