[30596] in Perl-Users-Digest
Perl-Users Digest, Issue: 1839 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 5 18:09:56 2008
Date: Fri, 5 Sep 2008 15:09:14 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 5 Sep 2008 Volume: 11 Number: 1839
Today's topics:
Re: "Selling" Perl (i.e. getting the boss to let me ins <john@castleamber.com>
Re: "Selling" Perl (i.e. getting the boss to let me ins <spamtrap@dot-app.org>
Re: "Selling" Perl (i.e. getting the boss to let me ins <jurgenex@hotmail.com>
Re: "Selling" Perl (i.e. getting the boss to let me ins <willem@stack.nl>
Re: "Selling" Perl (i.e. getting the boss to let me ins <vilain@NOspamcop.net>
Re: "Selling" Perl (i.e. getting the boss to let me ins <john@castleamber.com>
Re: "Selling" Perl (i.e. getting the boss to let me ins <john@castleamber.com>
Re: "Selling" Perl (i.e. getting the boss to let me ins <willem@stack.nl>
Re: "Selling" Perl (i.e. getting the boss to let me ins <cwilbur@chromatico.net>
Complex (for me) reference deconstruction sjcampbl@gmail.com
Re: Complex (for me) reference deconstruction <mark.clementsREMOVETHIS@wanadoo.fr>
Re: Complex (for me) reference deconstruction <jimsgibson@gmail.com>
Re: Data type mismatch warning using DBI <ldolan@thinkinghatbigpond.net.au>
Re: Data type mismatch warning using DBI <smallpond@juno.com>
Re: Data type mismatch warning using DBI <glex_no-spam@qwest-spam-no.invalid>
Re: Data type mismatch warning using DBI <mritty@gmail.com>
submit to FormMail.pl throwing some error. <vsrawat@gmail.com>
Re: submit to FormMail.pl throwing some error. <fawaka@gmail.com>
Re: submit to FormMail.pl throwing some error. <vsrawat@gmail.com>
Re: submit to FormMail.pl throwing some error. <joost@zeekat.nl>
Re: submit to FormMail.pl throwing some error. <glex_no-spam@qwest-spam-no.invalid>
Re: submit to FormMail.pl throwing some error. <glex_no-spam@qwest-spam-no.invalid>
Re: submit to FormMail.pl throwing some error. <john@castleamber.com>
Re: submit to FormMail.pl throwing some error. <joost@zeekat.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 5 Sep 2008 15:58:40 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <Xns9B106FAC6AC09castleamber@130.133.1.4>
"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> wrote:
> OK -- maybe a little. But I would not care to work in a place that
> won't allow me to install recognized useful tools on my system. It is
> certainly management's call as to what makes it into production
> environments but developers should rightly be able to manage their own
> environments.
It was not clear to me if the OP was a developer.
As a freelancer I have been working on locations a few times (in the
beginning), and there was often a policy in place for installing new
software. It was not forbidden, but you had to motivate it.
> In some shops you can't install VI. Those aren't
> serious development organizations and I would stay away.
I can't see why. Over the years I have learned to be flexible.
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: Fri, 05 Sep 2008 13:01:23 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <m1d4jicysc.fsf@dot-app.org>
"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
> In some
> shops you can't install VI. Those aren't serious development organizations
> and I would stay away.
Some developers believe that they can't possibly write a single line
of code without their favorite editor or IDE. Those aren't serious
developers and I would stay away.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 05 Sep 2008 10:20:00 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <k0q2c45g7kfb02soo7f4sgs3rpak4995hr@4ax.com>
Sherm Pendley <spamtrap@dot-app.org> wrote:
>"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>> In some
>> shops you can't install VI. Those aren't serious development organizations
>> and I would stay away.
>
>Some developers believe that they can't possibly write a single line
>of code without their favorite editor or IDE. Those aren't serious
>developers and I would stay away.
Well, there is certainly a big difference in ease and convenience
(important to the developer) as well as productivity (should be
important to the employer) when using something very basic like ed,
edlin, or even Notepad compared to an editor with all the bells and
whistles like syntax highlighting, automated indentation, command
completion, ...
Once you got a sophisticated editor then indeed it shouldn't matter that
much which one you are using.
jue
------------------------------
Date: Fri, 5 Sep 2008 20:14:42 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <slrngc34pi.atu.willem@snail.stack.nl>
Sherm Pendley wrote:
) "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
)> In some
)> shops you can't install VI. Those aren't serious development organizations
)> and I would stay away.
)
) Some developers believe that they can't possibly write a single line
) of code without their favorite editor or IDE. Those aren't serious
) developers and I would stay away.
Some managers believe that the opinions of a developer, on issues such as
the correlation between editor familiarity and productivity, should not be
taken seriously. Those aren't serious managers and I would stay away.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Fri, 05 Sep 2008 13:17:11 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <vilain-1F650B.13171105092008@comcast.dca.giganews.com>
In article <m1d4jicysc.fsf@dot-app.org>,
Sherm Pendley <spamtrap@dot-app.org> wrote:
> "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>
> > In some
> > shops you can't install VI. Those aren't serious development organizations
> > and I would stay away.
>
> Some developers believe that they can't possibly write a single line
> of code without their favorite editor or IDE. Those aren't serious
> developers and I would stay away.
>
> sherm--
In contrast, a friend just "escaped" from Agilent a while back. He came
away with some very interesting "prejudices" about development
environments. One he holds as a hard fast rule--he'll ask in an
interview what version control software they use. If it Clearcase,
he'll cut the interview short, thank the interviewer and leave as
quickly as possible. From my friend's perspective, any company that
uses "Clearcurse" is taking the tool selection out of the developer's
hands where it belongs. Clearcase sells well to management but anyone
who's tried to use it would immediately dismiss it as unusable.
I asked him what the main issues were as I've had clients who've had no
problems with Clearcase and didn't see why he was so vehement about it.
Before his small company was acquired by Agilent, they used CVS. It
worked OK and you could check out stuff from home and work over a DSL
line without a problem. "Clearcurse" took 10-30 minutes to check out a
single file over his DSL line. Other developers on the team have lost
lots of stuff to this beast and it was universally reviled. But it was
the Agilent standard and they had to use it.
I can see this as a possibility as it was likely developed for in-house
versioning with a resident Clearcase person on a release team all living
on a local LAN. The idea of remote developers probably wasn't on the
horizon in 1992. The Wikipedia article has a full list of issues.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]
------------------------------
Date: 5 Sep 2008 20:53:57 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <Xns9B10A1BC16825castleamber@130.133.1.4>
Willem <willem@stack.nl> wrote:
> Sherm Pendley wrote:
> ) "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
> )> In some
> )> shops you can't install VI. Those aren't serious development
> organizations )> and I would stay away.
> )
> ) Some developers believe that they can't possibly write a single line
> ) of code without their favorite editor or IDE. Those aren't serious
> ) developers and I would stay away.
>
> Some managers believe that the opinions of a developer, on issues such
> as the correlation between editor familiarity and productivity, should
> not be taken seriously.
Wouldn't amaze me if those managers had in many cases a point. Sorry about
that news, it's probably not what you want to hear :-D
For the record, I am a freelance developer, and have learned a long time
ago that productivity is sooner limited by that gray stuff between the
ears than anything else. Probably because I had so often to make do what
was available.
I would have no problem with coding in Notepad. Of course I would miss
some things (and probably would write some small Perl scripts to fix
that), but most of my coding is typing out stuff. Thinking happens (here)
on paper :-).
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: 5 Sep 2008 20:56:49 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <Xns9B10A23971780castleamber@130.133.1.4>
Sherm Pendley <spamtrap@dot-app.org> wrote:
> "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>
>> In some
>> shops you can't install VI. Those aren't serious development
>> organizations and I would stay away.
>
> Some developers believe that they can't possibly write a single line
> of code without their favorite editor or IDE. Those aren't serious
> developers and I would stay away.
Amen to that :-). I do most my coding in TextPad, and several years back I
suddenly had to use vim. After a day or 2 I was used to it (I had used
vi/vim in the past but not that excessive).
Same with version control. I am used to subversion now, but that's just
because I like TortoiseSVN a lot. Doesn't mean that I suddenly would be
crippled if I have to use svn on the cli. The ideas are the same.
And if I miss something, I code it; I am a programmer :-).
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: Fri, 5 Sep 2008 21:17:26 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <slrngc38f6.ce4.willem@snail.stack.nl>
John Bokma wrote:
) Wouldn't amaze me if those managers had in many cases a point. Sorry about
) that news, it's probably not what you want to hear :-D
s/news/opinion/ :-)
) For the record, I am a freelance developer, and have learned a long time
) ago that productivity is sooner limited by that gray stuff between the
) ears than anything else. Probably because I had so often to make do what
) was available.
)
) I would have no problem with coding in Notepad. Of course I would miss
) some things (and probably would write some small Perl scripts to fix
) that), but most of my coding is typing out stuff. Thinking happens (here)
) on paper :-).
Most of my work consists of working on existing code, finding out where to
make changes, finding out how things work, and then making small changes in
several places. In such cases, certain features are invaluable.
In any case, you're talking about 'problem coding on other than favourite
editor' while I'm talking about 'being faster in favourite editor'.
So if most of your work is typing out stuff then, yes, you won't be much
faster in another editor. But if most of your work is *editing* stuff,
then I *will* be much faster, in my opinion.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Fri, 05 Sep 2008 17:55:11 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: "Selling" Perl (i.e. getting the boss to let me install it)
Message-Id: <864p4u6yww.fsf@mithril.chromatico.net>
>>>>> "W" == Willem <willem@stack.nl> writes:
W> Some managers believe that the opinions of a developer, on issues
W> such as the correlation between editor familiarity and
W> productivity, should not be taken seriously. Those aren't
W> serious managers and I would stay away.
Indeed. On the other hand, this is what interviews are for: they are
just as much for the potential employee to evaluate the company as for
the company to evaluate the potential customer. I've turned down jobs
because they were needlessly restrictive about work environment and
development environment, because I know what I like and I know what I
find annoying, and I don't really want to spend 8 hours a day being
annoyed because my manager thinks my comfort level with the tools I'm
using is less important than a foolish consistency on everyone's desktop.
I mean, we're working with *text files*. "Standardizing" on a single
editor, or even on a single platform, is dim. The group I work in has
people on Macs, Windows, and Linux, and I couldn't tell you what most of
the people use for editors. This is a good thing.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Fri, 5 Sep 2008 09:52:55 -0700 (PDT)
From: sjcampbl@gmail.com
Subject: Complex (for me) reference deconstruction
Message-Id: <08d0b85d-977c-4536-a14f-78f7c2a6df10@w24g2000prd.googlegroups.com>
Hi and TIA.
Following is a snippet of code which uses HTML::TableContentParser to
pull table data out of an HTML page. I've gotten it to work, but, I'd
like to better understand why/how (particularly the long array/hash
references). I've read the Perllol and Perlref documents, but would
really appreciate a plain language walk-through. Thanks.
my $cServerInventoryURL = '...';
my $cServerInventoryHTML = get $cServerInventoryURL || die "Couldn't
get $cServerInventoryURL";
$p = HTML::TableContentParser->new(); # This seems to assign
a reference handle for the parser object
$tables = $p->parse($cServerInventoryHTML); # This assigns a
reference to an array containing all the tables in the HTML
$t=$tables->[5]; # This
appears to assign a reference to the 6th table object in the HTML page
##### HERE ARE THE REFERENCES IN QUESTION. THEY WORK, I JUST AM NOT
CLEAR WHY #####
for $r (@{$t->{rows}}) {
$cell2=$r->{cells}[1]{data}; #Cell 2 contains server name
$cell9=$r->{cells}[8]{data}; #Cell 9 contains environment list
print "-------------------------\n";
print " cell2 - $cell2\n";
print " cell9 - $cell9\n";
}
------------------------------
Date: Fri, 05 Sep 2008 18:43:43 +0000
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: Complex (for me) reference deconstruction
Message-Id: <48c17ddf$0$869$ba4acef3@news.orange.fr>
sjcampbl@gmail.com wrote:
> Hi and TIA.
>
> Following is a snippet of code which uses HTML::TableContentParser to
> pull table data out of an HTML page. I've gotten it to work, but, I'd
> like to better understand why/how (particularly the long array/hash
> references). I've read the Perllol and Perlref documents, but would
> really appreciate a plain language walk-through. Thanks.
>
> my $cServerInventoryURL = '...';
> my $cServerInventoryHTML = get $cServerInventoryURL || die "Couldn't
> get $cServerInventoryURL";
>
> $p = HTML::TableContentParser->new(); # This seems to assign
> a reference handle for the parser object
> $tables = $p->parse($cServerInventoryHTML); # This assigns a
> reference to an array containing all the tables in the HTML
> $t=$tables->[5]; # This
OK - so $t now contains a reference to a hash, $tables containing an
arrayref (a reference to an array). Try using Data::Dumper to print it out.
use Data::Dumper;
print Dumper $t;
This will be your greatest aid in understanding the structure.
> appears to assign a reference to the 6th table object in the HTML page
>
> ##### HERE ARE THE REFERENCES IN QUESTION. THEY WORK, I JUST AM NOT
> CLEAR WHY #####
> for $r (@{$t->{rows}}) {
The hashref pointed to by $t contains an element "rows", which is itself
an arrayref. We need to deference the reference to be able to use most
array operators on it. "for" in this context (also "foreach") sets $r to
be a reference to each element of the arrayref in turn.
> $cell2=$r->{cells}[1]{data}; #Cell 2 contains server name
> $cell9=$r->{cells}[8]{data}; #Cell 9 contains environment list
This syntax is syntactic sugar: written out longhand it would read
$cell2 = $r->{cells}->[1]->{data};
So: $r is a hashref containing an element "cells", that is itself an
arrayref. ->[1] dereferences the second element of this arrayref, giving
a hashref with an element "data", which gives a scalar value.
You need to be running under
use strict;
use warnings;
Check out the docs - for example perlstyle or perlfaq3 - for why.
Mark
------------------------------
Date: Fri, 05 Sep 2008 12:22:45 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Complex (for me) reference deconstruction
Message-Id: <050920081222458634%jimsgibson@gmail.com>
In article
<08d0b85d-977c-4536-a14f-78f7c2a6df10@w24g2000prd.googlegroups.com>,
<sjcampbl@gmail.com> wrote:
> Hi and TIA.
>
> Following is a snippet of code which uses HTML::TableContentParser to
> pull table data out of an HTML page. I've gotten it to work, but, I'd
> like to better understand why/how (particularly the long array/hash
> references). I've read the Perllol and Perlref documents, but would
> really appreciate a plain language walk-through. Thanks.
>
> my $cServerInventoryURL = '...';
> my $cServerInventoryHTML = get $cServerInventoryURL || die "Couldn't
> get $cServerInventoryURL";
>
> $p = HTML::TableContentParser->new(); # This seems to assign
> a reference handle for the parser object
> $tables = $p->parse($cServerInventoryHTML); # This assigns a
> reference to an array containing all the tables in the HTML
> $t=$tables->[5]; # This
> appears to assign a reference to the 6th table object in the HTML page
HTML::TableContentParser->parse() returns a reference to an array, with
each element of that array corresponding to one of the tables in the
HTML source.
>
> ##### HERE ARE THE REFERENCES IN QUESTION. THEY WORK, I JUST AM NOT
> CLEAR WHY #####
> for $r (@{$t->{rows}}) {
$t contains a reference to a hash.
$t->{rows} is the value of the element of that hash with key 'rows',
which contains a reference to an array -- one element per row of the
table. $r will iterate over the rows in the table.
> $cell2=$r->{cells}[1]{data}; #Cell 2 contains server name
$r is a reference to a hash.
$r->{cells} is an element of that hash, which is a reference to an
array.
$r->{cells}[1] is the second element of that array, which is a
reference to a hash.
$r->{cells}[1]{data} is the value of that hash with key 'data', and
contains the non-table-tag content of the cell of that table, the
server name.
> $cell9=$r->{cells}[8]{data}; #Cell 9 contains environment list
Likewise
HTH.
--
Jim Gibson
------------------------------
Date: Fri, 05 Sep 2008 15:09:34 GMT
From: "Peter Jamieson" <ldolan@thinkinghatbigpond.net.au>
Subject: Re: Data type mismatch warning using DBI
Message-Id: <OYbwk.34241$IK1.23986@news-server.bigpond.net.au>
"smallpond" <smallpond@juno.com> wrote in message
news:94fd545e-25d2-4452-aad3-2bb6b5fa624c@y38g2000hsy.googlegroups.com...
> On Sep 4, 11:38 pm, "Peter Jamieson"
> <ldo...@thinkinghatbigpond.net.au> wrote:
>> I am using Perl 5.8 with the DBI module to routinely send parsed data to
>> an
>> Access db.
>> Sometimes the incoming files may have errors so that numeric data appears
>> as
>> text.
>> This causes my script to throw a warning:
>>
>> DBD::ODBC::st execute failed: [Microsoft][ODBC Microsoft Access Driver]
>> Data
>> type
>> mismatch in criteria expression. (SQL-22018) at C:\myscript.pl line 422.
>>
>> When this happens the script contiues to run and on looking at the db the
>> particular
>> record is absent.
>> What I would like to happen is for my script to die when the above
>> warning
>> occurs so that
>> I can examine the input file to see what was causing the data type
>> mismatch
>> and rectify
>> the error.
>>
>> I have checked some DBI tutorials but cannot locate any way of doing
>> this.
>> Any suggestions or help appreciated!
>
>
> "DBD::ODBC::st execute failed" is not a warning. Are you checking
> that
> the call at line 422 succeeded?
>
> --S
Thanks for your input smallpond!
Line 422 is simply the: $input->execute($field1,$field2....etc) line in my
script.
Printing out the values of each field can be done of course to detect the
errant
data in the file (usually a typo) but as the script runs unattended to
process thousands of files it
is not practical since the file with the error is not known in advance.
What I seek is for my code to stop or pause thus warning me that a data-type
error was encountered. Hope this makes sense?
------------------------------
Date: Fri, 5 Sep 2008 08:50:57 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Data type mismatch warning using DBI
Message-Id: <95157207-a9ba-4ace-bc84-5fd13305bbf1@f36g2000hsa.googlegroups.com>
On Sep 5, 11:09 am, "Peter Jamieson"
<ldo...@thinkinghatbigpond.net.au> wrote:
> "smallpond" <smallp...@juno.com> wrote in message
>
> news:94fd545e-25d2-4452-aad3-2bb6b5fa624c@y38g2000hsy.googlegroups.com...
>
>
>
> > On Sep 4, 11:38 pm, "Peter Jamieson"
> > <ldo...@thinkinghatbigpond.net.au> wrote:
> >> I am using Perl 5.8 with the DBI module to routinely send parsed data to
> >> an
> >> Access db.
> >> Sometimes the incoming files may have errors so that numeric data appears
> >> as
> >> text.
> >> This causes my script to throw a warning:
>
> >> DBD::ODBC::st execute failed: [Microsoft][ODBC Microsoft Access Driver]
> >> Data
> >> type
> >> mismatch in criteria expression. (SQL-22018) at C:\myscript.pl line 422.
>
> >> When this happens the script contiues to run and on looking at the db the
> >> particular
> >> record is absent.
> >> What I would like to happen is for my script to die when the above
> >> warning
> >> occurs so that
> >> I can examine the input file to see what was causing the data type
> >> mismatch
> >> and rectify
> >> the error.
>
> >> I have checked some DBI tutorials but cannot locate any way of doing
> >> this.
> >> Any suggestions or help appreciated!
>
> > "DBD::ODBC::st execute failed" is not a warning. Are you checking
> > that
> > the call at line 422 succeeded?
>
> > --S
>
> Thanks for your input smallpond!
>
> Line 422 is simply the: $input->execute($field1,$field2....etc) line in my
> script.
> Printing out the values of each field can be done of course to detect the
> errant
> data in the file (usually a typo) but as the script runs unattended to
> process thousands of files it
> is not practical since the file with the error is not known in advance.
> What I seek is for my code to stop or pause thus warning me that a data-type
> error was encountered. Hope this makes sense?
execute returns a value which you have to check to see whether it
succeeded
or failed. One way to do that might be:
$input->execute($field1,$field2....etc) or
myprint_the_error_and_die_sub($input->errstr, $thisfilename, $NR,
$field1, $field2, ...);
--S
------------------------------
Date: Fri, 05 Sep 2008 10:54:01 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Data type mismatch warning using DBI
Message-Id: <48c15619$0$48215$815e3792@news.qwest.net>
Peter Jamieson wrote:
> "smallpond" <smallpond@juno.com> wrote in message
> news:94fd545e-25d2-4452-aad3-2bb6b5fa624c@y38g2000hsy.googlegroups.com...
>> On Sep 4, 11:38 pm, "Peter Jamieson"
>> <ldo...@thinkinghatbigpond.net.au> wrote:
>>> I am using Perl 5.8 with the DBI module to routinely send parsed data to
>>> an
>>> Access db.
>>> Sometimes the incoming files may have errors so that numeric data appears
>>> as
>>> text.
>>> This causes my script to throw a warning:
>>>
>>> DBD::ODBC::st execute failed: [Microsoft][ODBC Microsoft Access Driver]
>>> Data
>>> type
>>> mismatch in criteria expression. (SQL-22018) at C:\myscript.pl line 422.
>>>
>>> When this happens the script contiues to run and on looking at the db the
>>> particular
>>> record is absent.
>>> What I would like to happen is for my script to die when the above
>>> warning
>>> occurs so that
>>> I can examine the input file to see what was causing the data type
>>> mismatch
>>> and rectify
>>> the error.
>>>
>>> I have checked some DBI tutorials but cannot locate any way of doing
>>> this.
>>> Any suggestions or help appreciated!
>>
>> "DBD::ODBC::st execute failed" is not a warning. Are you checking
>> that
>> the call at line 422 succeeded?
>>
>> --S
>
> Thanks for your input smallpond!
>
> Line 422 is simply the: $input->execute($field1,$field2....etc) line in my
> script.
> Printing out the values of each field can be done of course to detect the
> errant
> data in the file (usually a typo) but as the script runs unattended to
> process thousands of files it
> is not practical since the file with the error is not known in advance.
> What I seek is for my code to stop or pause thus warning me that a data-type
> error was encountered. Hope this makes sense?
As 'smallpond' asked, "Are you checking that the call at line 422
succeeded?"
Check the documentation ( perldoc DBI ) for RaiseError or do what
'smallpond' is suggesting and check that the call succeeded. You
may print out something and wait for input, send you E-Mail, or die
if it fails. Examples of doing this also is conveniently included
in the documentation and on thousands of Web sites.
$sth->execute($product_code, $qty, $price) or die $dbh->errstr;
perldoc -f die
------------------------------
Date: Fri, 5 Sep 2008 09:43:31 -0700 (PDT)
From: Paul Lalli <mritty@gmail.com>
Subject: Re: Data type mismatch warning using DBI
Message-Id: <e2932151-0a06-4ded-8d71-5027a7ddae5d@c58g2000hsc.googlegroups.com>
On Sep 4, 11:38=A0pm, "Peter Jamieson"
<ldo...@thinkinghatbigpond.net.au> wrote:
> I am using Perl 5.8 with the DBI module to routinely send parsed data to =
an
> Access db. Sometimes the incoming files may have errors so that numeric d=
ata
> appears as text. This causes my script to throw a warning:
>
> DBD::ODBC::st execute failed: [Microsoft][ODBC Microsoft Access Driver] D=
ata
> type=A0mismatch in criteria expression. (SQL-22018) at C:\myscript.pl lin=
e 422.
>
> When this happens the script contiues to run and on looking at the db the
> particular record is absent.
> What I would like to happen is for my script to die when the above warnin=
g
> occurs so that I can examine the input file to see what was causing the d=
ata
> type mismatch and rectify the error.
It sounds to me like you have PrintError turned on, but want
RaiseError turned on instead.
You can read the docs for DBI, but basically:
$dbh->{RaiseError} =3D 1;
near the beginning of your db work, after the $dbh is created.
Paul Lalli
------------------------------
Date: Sat, 06 Sep 2008 01:16:05 +0530
From: V S Rawat <vsrawat@gmail.com>
Subject: submit to FormMail.pl throwing some error.
Message-Id: <g9s29v$d14$1@aioe.org>
I am creating a website.
The website root is /www at server.
my file ContactUs.html is kept in /www
FormMail.pl is kept in /www/cgi-bin
It was downloaded from
http://nms-cgi.sourceforge.net/formmail_compat-3.14c1/FormMail.pl
No changes done.
.FormMail.conf is also at /www
When I click submit, instead of displaying thanks.html (in the same
folder, it shows this message:
--start
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, webmaster@mydomain.com and
inform them of the time the error occurred, and anything you might have
done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use
an ErrorDocument to handle the request.
--end
HTML SOURCE
--start
<form id=contactform action="/cgi-bin/FormMail.pl" method=post>
<input type=hidden id=recipient value="myid@mydomain.com">
<input type=hidden id=subject value="Website Contact Form">
<input type=hidden id=redirect value="Thanks.html">
<input type=hidden id=sort value="order:email,comments">
<input type=hidden id=required
value="email,realname,comments">
<table>
<tr>
<td> </td>
<td>* marked fields are mandatory.</td>
</tr>
<tr>
<td align=right>*Your Name:</td>
<td><input type=text id=realname maxlength=100
style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>Address Line 1:</td>
<td><input type=text id=address_line1
maxlength=100 style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>Address Line 2:</td>
<td><input type=text id=address_line2
maxlength=100 style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>Phone:</td>
<td><input type=text id=phone maxlength=100
style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>*Email:</td>
<td><input type=text id=email maxlength=100
style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td style="text-align: right;
vertical-align:top">*Comments:</td>
<td><textarea id=comments rows=4 cols=25
style="width: 220px; height: 80px; color: #00267F; font-weight: bold;
background-color: lightblue; white-space: pre; overflow:
auto"></textarea></td>
</tr>
<tr>
<td></td>
<td align=right><input type=submit id=submit
value=Submit style="color: #00267F; font-weight: bold; background-color:
lightblue"></td>
</tr>
</table>
</form>
--end
What went wrong?
It was working OK during the day. I did some tweaking and it is not
working now.
btw, where are server logs kept. I am not able to find anything on server.
Thanks.
--
Rawat
------------------------------
Date: 05 Sep 2008 20:12:36 GMT
From: Leon Timmermans <fawaka@gmail.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <48c192b4$0$199$e4fe514c@news.xs4all.nl>
On Sat, 06 Sep 2008 01:16:05 +0530, V S Rawat wrote:
> I am creating a website.
>
> The website root is /www at server.
>
> my file ContactUs.html is kept in /www
>
> FormMail.pl is kept in /www/cgi-bin
> It was downloaded from
> http://nms-cgi.sourceforge.net/formmail_compat-3.14c1/FormMail.pl No
> changes done.
>
> .FormMail.conf is also at /www
>
Oy vey! That script is mess. Please do yourself a favor and get something
better.
> What went wrong?
>
> It was working OK during the day. I did some tweaking and it is not
> working now.
>
> btw, where are server logs kept. I am not able to find anything on
> server.
Without server logs, we can't say anything. You could add
use CGI::Carp qw(fatalsToBrowser);
To your script to get those errors to your browser. That will hopefully
make clear what's wrong.
Regards,
Leon
------------------------------
Date: Sat, 06 Sep 2008 01:58:49 +0530
From: V S Rawat <vsrawat@gmail.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <g9s4q0$st8$1@aioe.org>
On 9/6/2008 1:42 AM India Time, _Leon Timmermans_ wrote:
> On Sat, 06 Sep 2008 01:16:05 +0530, V S Rawat wrote:
>
>> I am creating a website.
>>
>> The website root is /www at server.
>>
>> my file ContactUs.html is kept in /www
>>
>> FormMail.pl is kept in /www/cgi-bin
>> It was downloaded from
>> http://nms-cgi.sourceforge.net/formmail_compat-3.14c1/FormMail.pl No
>> changes done.
>>
>> .FormMail.conf is also at /www
>>
>
> Oy vey! That script is mess. Please do yourself a favor and get something
> better.
>
>> What went wrong?
>>
>> It was working OK during the day. I did some tweaking and it is not
>> working now.
>>
>> btw, where are server logs kept. I am not able to find anything on
>> server.
>
> Without server logs, we can't say anything. You could add
> use CGI::Carp qw(fatalsToBrowser);
> To your script to get those errors to your browser. That will hopefully
> make clear what's wrong.
>
> Regards,
>
> Leon
Thanks,
I had googled and downloaded one of the scripts for it. Any tips where
can I better one?
Thanks.
--
V
------------------------------
Date: Fri, 05 Sep 2008 22:37:09 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <87k5dqnxca.fsf@zeekat.nl>
V S Rawat <vsrawat@gmail.com> writes:
> --start
> Internal Server Error
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
>
> Please contact the server administrator, webmaster@mydomain.com and
> inform them of the time the error occurred, and anything you might
> have done that may have caused the error.
>
> More information about this error may be available in the server error log.
>
> Additionally, a 404 Not Found error was encountered while trying to
> use an ErrorDocument to handle the request.
So what's in the error logs?
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Fri, 05 Sep 2008 15:53:45 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <48c19c59$0$89384$815e3792@news.qwest.net>
V S Rawat wrote:
[...]
> When I click submit, instead of displaying thanks.html (in the same
> folder, it shows this message:
>
> --start
> Internal Server Error
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
[...]
> What went wrong?
>
> It was working OK during the day. I did some tweaking and it is not
> working now.
Ahhh.. that's probably what went wrong.
> btw, where are server logs kept. I am not able to find anything on server.
Wherever your server is configured to put them. /var/log/httpd-error.log?
First, ensure you don't have a typo: perl -c FormMail.pl
Second, look at your 'tweeking', for problems. Compare the original with
your version.
Third, as the user that's running your Web server, try to run it via the
command line: ./FormMail.pl
------------------------------
Date: Fri, 05 Sep 2008 15:55:32 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <48c19cc4$0$89384$815e3792@news.qwest.net>
V S Rawat wrote:
[...]
> When I click submit, instead of displaying thanks.html (in the same
> folder, it shows this message:
Also. You refer to 'thanks.html', but your HTML shows:
> <input type=hidden id=redirect value="Thanks.html">
------------------------------
Date: 5 Sep 2008 21:00:39 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <Xns9B10A2DF8E6D2castleamber@130.133.1.4>
V S Rawat <vsrawat@gmail.com> wrote:
> my file ContactUs.html is kept in /www
Tip: you might want to rename it to contact-us.html
> FormMail.pl is kept in /www/cgi-bin
Advice: you might want to keep your cgi-bin side by side with www, not
*in* www (i.e. your DOCUMENT_ROOT),
> .FormMail.conf is also at /www
Advice: keep it out both www and cgi-bin. It should never be in www IMO.
> Internal Server Error
Check your error_log.
Also, if you edit the file locally, it's often a very smart thing to
perl -c FormMail.pl
before you upload.
> btw, where are server logs kept. I am not able to find anything on
> server.
Ask the company you're hiring webspace from.
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
------------------------------
Date: Fri, 05 Sep 2008 23:38:49 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: submit to FormMail.pl throwing some error.
Message-Id: <87fxoenuhi.fsf@zeekat.nl>
John Bokma <john@castleamber.com> writes:
> V S Rawat <vsrawat@gmail.com> wrote:
>
>> my file ContactUs.html is kept in /www
>
> Tip: you might want to rename it to contact-us.html
Maybe, but the're no technical reason to do so.
>> FormMail.pl is kept in /www/cgi-bin
>
> Advice: you might want to keep your cgi-bin side by side with www, not
> *in* www (i.e. your DOCUMENT_ROOT),
Again, there's no real reason to do so. And separating files out by
"type" can really mess up your website/code structure. IMO it's much
better to keep files that are functionally related together.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1839
***************************************
