DinosaurCoder
Programmer
A current project brought this up. I'm bumping two identical ISAM files against each other. For every record in file1 I look to see if there's a matching record in file2. If there is and the values of select fields are different I update those fields and rewrite the record in file2. Pretty simple.
Open file1 INPUT. Open file2 I-O. READ NEXT file1. Now here's the question. For an efficiency viewpoint, is it better to perform a START EQUALS on file2 to check for a matching record or jump straight to a READ WITH LOCK. The START will tell me if the record exists in file2, but if it does I wasted time because now I need to READ WITH LOCK anyway. Both commands reposition the record pointer, but the READ will attempt to return data if there's a record. Of course if there's no matching record that time is nil. Then there's the overhead for file2's record locking logic. (I need to lock any record I am updating.)
Actually, I think I just answered my own question. If I perform a START EQUALS the file system only attempts to reposition the file pointer and reports back if it was successful. That's pretty quick. If I attempt to READ WITH LOCK the file system also first attempts to reposition the file pointer. If the record isn't there it's done and returns to me the same "record not found" status. That should happen in the same amount of time as the START command. If the record does exist it would then lock the record and load the record buffer. So I should just perform the READ WITH LOCK every time.
Anything wrong with that logic ?
Open file1 INPUT. Open file2 I-O. READ NEXT file1. Now here's the question. For an efficiency viewpoint, is it better to perform a START EQUALS on file2 to check for a matching record or jump straight to a READ WITH LOCK. The START will tell me if the record exists in file2, but if it does I wasted time because now I need to READ WITH LOCK anyway. Both commands reposition the record pointer, but the READ will attempt to return data if there's a record. Of course if there's no matching record that time is nil. Then there's the overhead for file2's record locking logic. (I need to lock any record I am updating.)
Actually, I think I just answered my own question. If I perform a START EQUALS the file system only attempts to reposition the file pointer and reports back if it was successful. That's pretty quick. If I attempt to READ WITH LOCK the file system also first attempts to reposition the file pointer. If the record isn't there it's done and returns to me the same "record not found" status. That should happen in the same amount of time as the START command. If the record does exist it would then lock the record and load the record buffer. So I should just perform the READ WITH LOCK every time.
Anything wrong with that logic ?
