use of DBI; I am getting multiple error messages mixed in with the correct output.
in [Perl]
|
Prev: use of DBI; I am getting multiple error messages mixed in with the correct output.
Next: FAQ 1.11 When shouldn't I program in Perl?
From: Ted Zlatanov on 23 Apr 2008 17:23 On Wed, 23 Apr 2008 13:40:58 -0700 (PDT) smallpond <smallpond(a)juno.com> wrote: s> Each call to fetchrow_arrayref gets a new row, but you s> only check numFields once. So your rows don't all have s> the same number of fields. That SELECT SQL query will not return a variable number of fields. The problem is that there are NULL values, which are undefined in the DBI translation. So this printf("%s%s", $i ? "," : "", $$ref[$i]); should be (for example) printf("%s%s", $i ? "," : "", $$ref[$i]||'NULL'); Of course, the code could be greatly improved with a join() call and in many other places, but I don't feel like rewriting the whole thing. Ted
From: Joost Diepenmaat on 23 Apr 2008 18:31 Ted <r.ted.byers(a)rogers.com> writes: [ on the conversion of NULL fields to <undefined> ] > This would be a useful tidbit to add to the documentation. I hadn't > expected a mature library like DBI to behave like this. Well, it is the most DWIM way of representing NULL values in perl. > I do not, for example, have to go through any such extra hoops when > using JDBC with JSF. If a particular record set contains nulls in one > or more columns in one or more records, JSF automagically displays it > as an empty string; something I have modified on occassion to display > the string "N/A". Perl does the same thing, but it will issue a warning if you have warnings enabled (warnings are output to STDERR, so if you're capturing STDOUT only it shouldn't be a problem - I haven't read all of the thread). *If* you don't want to deal with that, either don't "use warnings" and don't use the -w flag, or do use them in general but disable warnings in the offending code block. In my opinon warnings are very useful and should be enabled as much as possible, but in the particular cases/constructs where it they cause problems, you shouldn't be afraid to disable them (using "no warnings"). See perldoc warnings and perldoc no. -- Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: Joost Diepenmaat on 23 Apr 2008 18:34 Joost Diepenmaat <joost(a)zeekat.nl> writes: > In my opinon warnings are very useful and should be enabled as much as > possible, but in the particular cases/constructs where it they cause ^^ disregard that > problems, you shouldn't be afraid to disable them (using "no > warnings"). See perldoc warnings and perldoc no. ^^ oops, there that doens't exist. See perldoc -f use -- Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: A. Sinan Unur on 23 Apr 2008 19:38 Ted <r.ted.byers(a)rogers.com> wrote in news:3b842be5-7145-42f6-9f5a- ad1c3a50ad35(a)x35g2000hsb.googlegroups.com: > table is returned. However, The correct output is punctuated about > every 100 lines by hundreds of error messages: "Use of uninitialized > value in printf at k:/MerchantData/MSDB.pl line 34." That is the > printf in the for loop within the while loop. This increases the > number of lines of output from precisely 529 to more than 1800! That > is almost three times as much garbage as there is real data. 1. Those are warnings, not errors. The difference matters. 2. By default, warnings go to STDERR. 3. The easiest way to deal with warnings is to avoid the behavior causing them. 4. After careful consideration, you may also choose to disable specific types of warnings in specific scopes. Read perldoc perllexwarn. Sinan -- A. Sinan Unur <1usa(a)llenroc.ude.invalid> (remove .invalid and reverse each component for email address) comp.lang.perl.misc guidelines on the WWW: http://www.rehabitation.com/clpmisc/
From: A. Sinan Unur on 23 Apr 2008 19:43
Ted <r.ted.byers(a)rogers.com> wrote in news:8db4922e-cd7e-4345-93cf- b3516d3cc01a(a)z72g2000hsb.googlegroups.com: > But, if I understand your final statement correctly, am I to belief it > is choking on the fact that some of the fields in some of the rows > have null values? There is no choking. perl is telling you that you have attempted to use an undefined value. > JDBC). But there is no a priori way to tell which columns in which > rows will be null. Therefore, you should check values with 'defined' and use suitable defaults before printing or manipulating them. > I have found it easy t work around nulls in SQL > and JDBC and C++, so what it the Perl counterpart to the routine > idioms I use in these other languages? I don't know what idioms you are talking about. In Perl, you check if a value is defined using perldoc -f defined Sinan -- A. Sinan Unur <1usa(a)llenroc.ude.invalid> (remove .invalid and reverse each component for email address) comp.lang.perl.misc guidelines on the WWW: http://www.rehabitation.com/clpmisc/ |