... we then have to go update the database to change the record from preissued to issued, the check number and timestamp... if the employee had 3 or more checks (they are combined into one check by the payroll processor)...

So, if you select "amount" from all records for a given "_emp_id" (the actual table column name for this is "apdid"), where "status='preissued'", the sum of the returned amounts should add up to the amount of the single check, right?

Given that the "_emp_id/apdid" and "status" fields identify the set of rows to be updated, you don't need to include the amounts as part of the query, do you? I presume it would be a good idea to test and report whether the sum of amounts in the database add up to the amount of a given check, but it would be easier to do this part in perl rather than in sql -- something like this maybe (untested):

my $get_amt = $dbh->prepare( qq{SELECT SUM(amount) FROM `pot` WHERE
   `apdid`=? AND `status`='preissue'} );

my $upd_pay = $dbh->prepare( qq{UPDATE `pot` SET `status`='issued',
   `checkno`=?,statuschanged=? WHERE `apdid`=? AND `status`='preissue'
+} );

my @file_fields = qw/checkNo checkAmt empID payDate/;

while ( my $_line = <IN> ) {  # assuming lines are coming from a file
    my %lineData = ();
    @lineData{@file_fields} = split /,/, $_line;

    $get_amt->execute( $lineData{empID} );
    my $rows = $get_amt->fetchall_arrayref;
    my $sum = 0;
    for my $row ( @$rows ) {
        my ( $amt ) = @$row;
        $sum += $amt;
    }
    if ( $sum != $lineData{checkAmt} ) {
        warn sprintf( "empID %s: mismatch: sum of preissue rows= %s, c
+heckAmt= %s\n",
            $lineData{empID}, $sum, $lineData{checkAmt} );
        next;
    }
    $upd_pay->execute( $lineData{checkNo}, $lineData{payDate}, $lineDa
+ta{empID} );
}
[download]

You might want more error checks on the DBI calls (unless you have RaiseError set to die on any failure). I would also recommend more error checks on reading the input data (correct number of fields, fields are non-empty, etc).

Note that the update statement will assign the current checkNo and payDate values (as well as resetting the status to "issued") for all the "preissue" rows for a given empID. This is a normal way of doing multi-row updates.

Also note that the statements are prepared once, outside the processing loop. This will save some overhead on the DB server.

You'll need to work out what really needs to be done when the amount of the check does not match the sum of "preissue" rows for a given employee, but I think the rest of it is basically what you want. (Or it could be that I don't get what you're doing at all.)

You understood me correctly, however the amount does matter, because it could be that they have other checks 'preissued' by the time we get the file from adp, that has the check numbers.

So the amounts are relevant, however, it will be the first ones I come to, as I don't upload a later file before an earlier one, so it could be that the amount will equal the FIRST 1 or more but not likely it would be the second and third and fourth but not the first...

So, what I need to do is something like this, I guess:

my $_startingAmount = sprintf('%.2f', $fileparts
[$_checkAmt]);
my @potids = ();
my $sth = $dbh->prepare(qq{SELECT * FROM `pot` WHERE `adpid` = ? AND `
+status` = "preissue" ORDER BYE `potid`});
$sth->execute($fileparts[$_emp_id]);
while(my $_pot = $sth->fetchrow_hashref()) {
 if(sprintf('%.2f', $_pot->{amount}) <= $_startingAmount) {
   push(@potids, $_pot->{potid});
   $_startingAmount -= $_pot->{amount};
   last if $_startingAmount == 0.00;
 }
 next;
}
$sth->finish();
## Now go update all the potid records in a foreach statement in @poti
+ds
[download]

I think I need to think that through, but it SHOULD work... but what if the payroll company messes up and he amounts do not match up... guess I could keep track of that in the while statement and if I never reach 0.00 set a flag for that record and don't update those records. Hmm, what do you think?

Thanks again for your input, BTW, the employee identifier is 'adpid' that is the record of the employee file primary key, unique to each employee (Currently we have just shy of 2,000 in that table).


thx,
Richard

... the amount does matter, because it could be that they have other checks 'preissued' by the time we get the file from adp, that has the check numbers.

In other words, between the time that a set of rows goes out for check processing, and the time when the check-processing results come back to you for updating the table, there might be additional "preissue" rows that have been inserted for a given "empID". Is that it?

In that case, you are missing a piece of information, which might be simple to add in the current table structure: the date when a given set of rows were sent out for check processing (i.e. when the status field was set to "preissue"). You appear to have a "statuschanged" field, which apparently holds a date value.

If that field is set when the status field becomes "preissue", and if a set of check-processing results can be associated with that date, then you can select "preissue" rows with "statuschanged" less-than-or-equal-to the particular date, and you should get the right set of rows (excluding the rows that were added after the current list of payments were sent out for processing).

Your alternative of looping over records until you reach the payment amount would most likely solve it as well, but seems like more work. (And you would have to fix the spelling: "ORDER BY" -- no final "E")

The advantage is that it's notably easier to group the preissues to match the combined checks. For example, it should make it easier to deal with special situations where the amount paid might (temporarily) not equal the amount owed.

Actually, that is a very good idea, I just was trying to keep the databases to a minimal, we already have over 350 tables in it, a little much... thx though
thx,
Richard