If you used Data::Dumper to look at your hash, you might be able to see more easily why things were screwing up. The first key you end up with is 1/5/2009 3:55:30 PM, which has a value of "Login". That's not what you want. You want to strip off the date beforehand.

I imagine that the dates are an important piece of information, so I don't think you'll want to get rid of them outright. And anyway, even if you did get rid of the dates, you'll have problems putting this into a hash. Hashes can only have one value per key, and your values repeat for each login record, so you'll just overwrite the first set of values.

If this is always the format of the data, then you could do something like the following:

use strict;
use warnings;

my $file = 'data.txt';

open my $fh, '<', $file or die "failed to open $file: $!";
my @tokens = split /,/, <$fh>;
close $fh;

chomp @tokens;

my $found_logout = 1;
my $date;
my $i = 0;
while ($i < @tokens) {
    if ($found_logout) {
        $date = $tokens[$i++];
        $found_logout = 0;
        print "*****************************\n";
        print "New date: $date\n";
    }
    else {
        my $key = $tokens[$i++];
        my $value = $tokens[$i++];
        
        print "$key = $value\n";

        # do DB stuff with $key and $value

        $found_logout = 1 if $key eq "Logout";
    }
}
[download]

I haven't used Win32::ODBC, but hopefully someone else can help you out with that part.

Update: And if you really need it in a hash:

my $found_logout = 1;
my $i = 0;
my %hash;
while ($i < @tokens) {
    if ($found_logout) {
        %hash = (date => $tokens[$i++]);
        $found_logout = 0;
    }
    else {
        my $key = $tokens[$i++];
        my $value = $tokens[$i++];

        $hash{$key} = $value;
        if ($key eq "Logout") {
            $found_logout = 1;
            do_db_stuff(\%hash);
        }
    }
}

sub do_db_stuff {
    print Dumper shift;
}
[download]

you are correct what I want to do with the date is add a new key called date into the hash so that it maps date->value, then login->time etc, I was thinking that inputting the data would need the column name, followed by the value, fields are always in same order in the data file, I would also like to add a value for site which would contain a code indicating which account is being measured. I really don't know where to go for figuring out how to get this into sql which is my main problem, seems there are not many examples out there for using parameters in a query programmatically I am guessing because stored procedures are the preferred mechanism for doing so. I don't want to build a stored procedure for it as I am not that versed in sql. I guess that would be a viable option to pursue though.

There seems to be some inconsistency on the sample data that lead me to think that this simple split on commas won't give you a correct hash representation of the information. You will need to study the file to better understand its structure and then find a proper way to parse it.

I'm not familiar with Win32::ODBC so I can't tell you if you are using it correctly but, I'd recommend that you look into the DBI documentation in order to learn how to connect to a database and execute queries on it. Take particular notice on placeholders.

Your SQL statement is wrong. Find an SQL cheat sheet (just to get you started) and look for the correct syntax for insert statements. Just search for sql syntax.

#!/usr/bin/perl

use strict;

while( <DATA> ) {
    s/,/\","/g;
    chomp;
    print "INSERT INTO dbo.RESULTS values (\"$_\");\n";
}

__DATA__
1/5/2009 3:55:30 PM,Login,18.490683,SearchLoad,15.012853,SearchCount,0
+:0.392878,SearchResults,16.048765,SearchSave,6.629372,SearchDelete,9.
+614098,SearchDetails
[download]

It always makes me uncomfortable to see “read the entire file into a ...” because basically what you are doing is using virtual-memory as a(nother) disk file. If you've already got the data as an existing flat-file, it seems to me that you ought to be reading it and processing it “a record at a time.”

Also, don't overlook any possibilities to take advantage of (disk-based) sorting. It's an uncommonly-fast and efficient operation, and when you're dealing with a sorted file you know that all of the records for any particular sort-key value must be adjacent ... or they're not there at all. I have not looked closely at your example so I really don't know if this applies to you. Anyhow, “it was good enough for COBOL and punched-cards and mangnetic tapes,” and those advantages still apply today.