>>This is a SWAG, but I'd think it would have something to do with the field/tag named: BLANK. This is a keyword and it's not a good idea to use keywords as fields or memory variables.
>>
>>I'll give you an example of this and what can happen, if you like.
>
>
>Thanks George,
>It seems like a reasonable possibility that this is causing the problem.
>I guess sometime between foxbase 2.0 and vfp 8.0 they made blank a keyword!
>It is no minor operation to change this throughout the databases and the programs but thanks to the code reference utility its a lot more manageable than it use to be =)
>
>Thank Very Much,
>
Eddie,

You're welcome.

Frankly, I figured that changing it might be a big deal and I hated to be the bearer of such news. However, considering VFP's locking scheme it might very well explain what's going on. For example, if you

APPEND BLANK

I believe that the header is locked while the record is added, then the record itself pending modification. Since the record SEEK is looking for isn't the result of an append...but like I said, purely a SWAG.

Keywords these days are pretty easy to spot because of syntax coloring. If you look back at your original post, you'll see that BLANK is in blue (the UT mirrors the syntax coloring) Here's an example of what can happen when keywords are used.

CREATE CURSOR Foo (Application C(20), Something I)
INSERT INTO Foo (Application, Something);
  VALUES ("Application Name", 0)
SCATTER MEMVAR

You'll get error 1930 with the SCATTER.