An easy way to avoid the warning -- and make sure you only insert rows that have the expected amount of actual data -- would be:

    my @db_values = split (/,/,$entry);

    next unless ( @db_values == 7 );  ## add this line

    $DB->sql("INSERT INTO Files ... ");
[download]

In your case (opening a file for input), die would say "No such file or directory" after you get the warning "Use of uninitialized value in open". Oddly enough when I just now tested an open for output with nothing in @ARGV, I got no warning, no error, and no output file -- which makes it a really tricky thing to catch. (That seems like a perl bug, and worthy of a separate thread...)

Anyway, you should always check input (from users or data files) before using it.

update: forgot to mention -- are you sure you want to be using DBI to insert stuff into the database? It's very slow and you have to do all the work yourself (which you have not been doing yet) of checking that the values are appropriate before inserting them. I expect that your database engine (whatever it is) has its own tool or method for inserting data from a file, which will run a lot quicker (and value checks are likely to be built-in); note that you can (and should) use perl to condition data in advance if needed, and to run that tool.

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]

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).

Do you perhaps have a blank line at the end of your input file so that for the last itteration of your loop you get undef for all the field entries?

"there is a blank line in the end of input file" this is the exact reason for this kind of warning.

Use the error message. Use of uninitialized value in concatenation (.) or string at C:\Perl\Orange\pop_db.pl line 18, <FILE> line 46062.

The key is "line 46062". Perl is telling you that the uninit value is encountered when executing line 18 of your program AND that the last line read from the last opened filehandle (FILE) was 46062. This information would provide useful except that you slurped in the entire file before processing it. Not only wasteful of memory but since everything in the loop happens after you read the whole file they *all* appear to happen at line 46062.

If you modify your code to process the file a line at a time the warning will identify for you exactly what line in the data is corrupt.

open (FILE, "$ARGV[0]") ||  die "\n$!\n";

print "\n\nPlease wait......Populating Database\n";
while(my $entry = <FILE>)
{
    chomp $entry;
    ...process $entry as normal...
}

close FILE;
[download]

Well, the offending line seems to be the one that starts with $DB->sql. Clearly, some element of @db_values is undefined. If that's OK with you, then do this:

    {
      no warnings 'uninitialized';
      $DB->sql("INSERT INTO Files (File_Path, File_Name, Size_Byte, Cr
+eated, Modified, Accessed, Type) VALUES ('$db_values[0]','$db_values[
+5]','$db_values[1]','$db_values[2]','$db_values[3]','$db_values[4]','
+$db_values[6]')");
    }
[download]

my @db_values = map defined( $_ ) ? $_ : '', split (/,/,$entry);
[download]

It would also assume that there were no bad characters in the data being inserted, as there's nothing in the code to escape them.

In a situation like this, I'd use bind variables, nulls were allowed. I'd use 'em even if nulls weren't allowed, I'd just verify my data before trying the insert:

my $sth = $DB->prepare( 'INSERT INTO Files ( File_Path, File_Name, Siz
+e_Byte, Created, Modified, Accessed, Type ) VALUES ( ?,?,?,?,?,?,? )'
+ );
foreach my $entry (@data)
{
    next if ($entry =~ /^start|^Full/i);
    my @db_values = split (/,/,$entry);
    # do whatever value checking here ... checking for 7 values, etc.
    $sth->execute( @db_values );
}
[download]

It wouldn't be bad to check for errors after doing an execute, either:

$sth->execute( @db_values )
  or warn $DB->errstr();
[download]