Have you tried printing the return value of your substr function? That might offer a clue.

For what it's worth, while this solution will work (once you get the length right), I think most monks would use a regex:

If the data is indeed CSV, and not pipe-separated, most monks would use a CSV parser and write

while (my $row = $csv->getline ($fh)) {
    $row->[0] eq "A.SERIAL_NUMBER||" and next;
    :
[download]

Giving the OP's code, I seriously doubt however that it is a CSV file.

If the file is a pipe-separated-value file, that can also be read with Text::CSV or Text::CSV_XS.


Enjoy, Have FUN! H.Merijn

While many people do use regular expressions, I think that's like using an M16 to crack walnuts.

R.E. are the appropriate solution when you have variable components, but testing a constant string is precisely what 'eq' is for.

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

You make a good point, but I found myself wondering how the combination of substr, length, and eq would compare to a single anchored regex, so I did a benchmark. I'm convinced!

bannor:~/work/perl/monks$ cat 968838.pl
#!/usr/bin/env perl
use Modern::Perl;
use Benchmark qw(:all);

my $str = 'A.SERIAL_NUMBER||abcdefghijklmnopqrstuvwxyz';
my $ss = 'A.SERIAL_NUMBER||';
my $yay;

cmpthese( 10_000_000, {
    'substr' => sub {
        if(substr($str,0,length($ss)) eq $ss ){
            $yay = 1;
        }
    },
    'regex'  => sub {
        if( $str =~ /^\Q$ss\E/ ){
            $yay = 1;
        }
    },
});

bannor:~/work/perl/monks$ perl 968838.pl
            Rate  regex substr
regex  1312336/s     --   -65%
substr 3802281/s   190%     --
[download]

Aaron B.
My Woefully Neglected Blog, where I occasionally mention Perl.

Pan20:

Why would you expect that a string X characters long would match one that's X-1 characters long? Remove the "-1".

...roboticus

When your only tool is a hammer, all problems look like your thumb.

I removed the -1 but it still doesnt work... the data is inserted to the table with no any issues but I' am still having the following error msg. DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''A.SERIAL_NUMBER||'',firmware_version=''||C.NAME||'',source_ip=''||A.SOURCE_IP||' at line 1 at /home/c8098/bin/new_srp_rms.pl line 191, <CSVFILE> line 5005.

Pan20:

It sounds like you've made some progress, as now you're seeing a different problem. That's the sort of message I would expect to see if your CSV file has a field in it containing an embedded quote in it. You can avoid those sorts of problems by using placeholders. (You can see them described in DBI under 'Placeholders and Bind Values'.) It lets you set up the code for your insert once, and then you can use it over and over, something like:

. . .
my $ST = $DB->prepare("insert into my_table(foo, bar, baz) values (?, 
+?, ?)");
. . .
code to prepare CSV file
. . .
# For each record, read it
while (my $fields = read_data_from_csv_file()) {
   # Ignore records we don't want
   next if $fields->{BLECCH} = 'REJECT';
   . . .
   other stuff
   . . .
   # Stuff our record into the database
   $ST->execute( $fields->{FOO}, $fields->{BAR}, $fields->{BAZ} );
}
[download]

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Pan20,

Just to add some thoughts about this:

• Could case (upper/lower) matter?
• I would use the very fast 'index' or 'rindex' for this.

Good Luck!