The Evil That Is WRITEV

Lately I've been seeing more instances of multiple back to back READVs reading different attributes out of the same record, and while that's disturbing, in my opinion it pales in comparison to multiple WRITEVs. In case it's not otherwise clear, I believe WRITEV may very well be the worst part of the Multivalue BASIC language, made even worse by putting a bunch of them back to back. For example:

READV NAME FROM F.FILE,KEY,1 ELSE NAME = ''
READV ADDRESS FROM F.FILE,KEY,2 ELSE ADDRESS = ''
NAME = 'BOB'
ADDRESS = '121 NE 4TH ST'
WRITEV NAME ON F.FILE,KEY,1
WRITEV ADDRESS ON F.FILE,KEY,2

So how many times will this one record be read?

While it looks like the record is read only twice by the READVs, the answer is 4 times as each WRITEV causes the record to be read again in order to replace the specific attributes. See, WRITEV is a syntax convention that reads the record, replaces the attribute, and then writes the record back out. It's designed for cases where you need to update an attribute but don't want to bother reading the record. (Then there's the whole discussion of record locking which is beyond the scope of today's tirade...)

This particular example, while contrived, is like many production examples where this peculiarity can be found in that the entire example can be achieved with 2 I/O operations: one read (with lock!) and one write. Instead, this example has 4 reads and 2 writes, a 300% increase in I/O! (Interestingly enough, I've seen some production examples with 5 or more READV/WRITEV combos.) Certainly the caching features of the database will help to some degree, but if all of the code is like this eventually the caching mechanism will be working so hard to keep up that it really won't offer much benefit, and some user - completely unaware of the nuances of the code - will be calling to complain.