1. When a DBI call fails, the error is not in $!. See the DBI docs.
2. There's an option to connect() that will have DBI provide more error information to you. See the DBI docs.
3. I don't see you issuing a disconnect, so perhaps it's possible to reuse $dbh, and avoid reconnecting from within print_form.
4. Arrange to print the Content-type: header before you might have to issue error message.
5. use CGI; and use the routines it provides to help you print the content header and HTML.
6. Are you sure you aren't off-by-one when indexing into @options ? I would think that the string for "Option 1" would be at $options[0], not $options[1].
7. You're embedding entirely too many "magic numbers" (including an IP address and background/font colors). That makes using and changing the script error-prone. Lift these values out into a set of configuration variables at the top of the script.

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;
[download]

This will give you more detail as 'to what is going on'.

Or even better:

my $dbh = DBI->connect(
   "DBI:${dbtype}:${dbname}", $dbuser, $dbpass),
   {RaiseError => 1},
);

# oops!
$dbh->prepare('slecet foo from baz');
[download]

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)

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

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.

use strict;

my @options = (
   'Perfect for me',
   'Okay, but my first choice was taken',
   'My real name, blame my parents',
   'Cowboy Neal',
);

for (0..$#options) {
   print "<tr>\n<td align='left' bgcolor='#8f4141'>\n";
   print "<font color='#eabf12' size='2'>\n";
   print qq|<input name="in_vote" type="radio" value="option_$_">$opti
+ons[$_]</font>\n|;
   print "</td>\n</tr>\n";
}
[download]

Lastly, your database schema is, i am sorry to say, not very good at all. At it's very simplest, you only need three tables (not including tables for user info):

1. id (primary key)
2. user_id (foreign key from user table - user who started poll)
3. description
4. date_started
5. date_ended

1. id (primary key)
2. poll_id (foreign key to poll table - which poll does this option belong to)
3. number (what order to place in poll)
4. description

1. user_id (foreign key to user table - who voted on this option)
2. option_id (foreign key to option table - which option was voted on)

select option.description from option
   inner join poll on option.poll_id = poll.id
   order by option.number
[download]

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)

Cheers, I'll keep that link...
but I have no problems with the mySQL its the DBI statements to connect to it.

Namely, the first query works, why don't the second two ? I assume it is DBI related as it checks out fine manually...

Cheers
lagrenouille

blokhead

G'day blokhead

yeah, I had considered a template... however this poll script is intended to be sitting within an index page, that has options down each side and has the vote script included via SSI.

Is it still ok to use templates given that the html I am printing is going to form merely a part of a much bigger html document ?

Cheers
lagrenouille

G'day greywolf

ok thanks, i'll try that...
( I know the mySQL commands are good, I tested them from the shell by copying and pasting, worked fine... )

I know about CGI::carp, I am using the script in an SSI situation and to have huge error messages printed out disturbs the tables a lot and is hard to read... so i've just been reading it out of the server logs

Thanks for your help!

Cheers
lagrenouille