Re^2: Most Annoying Error : Use of uninitialized value in concatenation (.) or string at C:\Perl\O

in reply to Re: Most Annoying Error : Use of uninitialized value in concatenation (.) or string at C:\Perl\O
in thread Most Annoying Error : Use of uninitialized value in concatenation (.) or string at C:\Perl\O

my @db_values = split (/,/,$entry);
next unless ( @db_values == 7 );  ## add this line
$DB->sql("INSERT INTO Files ... ");
[download]

I don't see how that would work if the array is actually filled with undef's. For example...

steve@kirk:~$ perl -wle'push @foo, undef for (0..6); print scalar @foo
+'
7
[download]

Your code will only work if you don't have 7 entries in the array. It doesn't do any more checking of the data than that. More checks are needed to guarantee it will work.

A more appropriate question, though, is why the OP is not letting the database do the work for him? jhourcle's entry below suggesting a prepare is probably the best reply here. Let the database do the checks for NULL values then. Simply turning off warnings is not really solving the problem. It's a bit like using duct tape. Its a repair, but not a real fix. Also, there should be a performace boost by not having to repeatedly reparse the insert multiple times.

Also, regarding the question on an empty $ARGV[0] to open(). I did run into issues, but I had not problems with it die'ing. My problem is that $! wasn't getting populated without using strict on a one-liner. I will open a perlbug for this problem, but I could not see where open was failing to behave as expected. Hopefully, I can get a fix for my problem done this evening.

steve@kirk:~$ perl -wle'open FOO, undef || die "FOO! $!";'
Name "main::FOO" used only once: possible typo at -e line 1.
FOO!  at -e line 1.
steve@kirk:~$ perl -Mstrict -wle'open FOO, undef || die "FOO! $!";'
Name "main::FOO" used only once: possible typo at -e line 1.
FOO! Bad file descriptor at -e line 1.
[download]

Comment on Re^2: Most Annoying Error : Use of uninitialized value in concatenation (.) or string at C:\Perl\O Select or Download Code

Replies are listed 'Best First'.
Re^3: Most Annoying Error : Use of uninitialized value in concatenation (.) or string at C:\Perl\O by graff (Chancellor) on Jul 15, 2005 at 19:22 UTC
I don't see how that would work if the array is actually filled with undef's. The way that split works (with the two argument call as in the OP), an empty or undef input string will yield a list of zero elements, so "scalar @db_values" in that case will be zero. Likewise, if the input string is something like just "a" or "a,,,,,,", split will return a list of just one element (scalar @db_values will be "1"), and so on; trailing separators, if any, are simply truncated. It's true that if a line of input text contained a string like ",,,,,,g", split will return a list of 7 elements, the first six of which will be undef. But in that case, it might actually be "right" to create a database record in which the first six fields are null. It's also true that more checking of input values, before sending them on to a database, would be prudent, and more efficient ways of inserting database rows are both available and recommended (e.g. using the DB engine's native file import tools).	[reply]

Replies are listed 'Best First'.

Re^3: Most Annoying Error : Use of uninitialized value in concatenation (.) or string at C:\Perl\O
by graff (Chancellor) on Jul 15, 2005 at 19:22 UTC

I don't see how that would work if the array is actually filled with undef's.

The way that split works (with the two argument call as in the OP), an empty or undef input string will yield a list of zero elements, so "scalar @db_values" in that case will be zero. Likewise, if the input string is something like just "a" or "a,,,,,,", split will return a list of just one element (scalar @db_values will be "1"), and so on; trailing separators, if any, are simply truncated.

It's true that if a line of input text contained a string like ",,,,,,g", split will return a list of 7 elements, the first six of which will be undef. But in that case, it might actually be "right" to create a database record in which the first six fields are null.

It's also true that more checking of input values, before sending them on to a database, would be prudent, and more efficient ways of inserting database rows are both available and recommended (e.g. using the DB engine's native file import tools).

[reply]

In Section Seekers of Perl Wisdom