Well, John, if you're basing your conclusion that you cannot USE...AGAIN a cursor, you should really LOOK through the code because I can USE...AGAIN a cursor by using DBF("< cursorname >") as the table name.

Like you I find this behaviour a little difficult to believe, so I'm grasping at things that ***MIGHT*** cause such behaviour.
If some other part of the program has need to use that cursor I could see it doing a USE AGAIN. And I have no idea how that would affect things, but it is the only thing I can come up with that could impact the normal behaviour.

My theory is a simple one - something seems to be causing VFP to treat the cursor as a non-exclusive entity. The only thing that comes to my mind is AGAIN.

good luck



>You are correct that "AGAIN" is not used. AGAIN would have to reference a table and this is, of course, a cursor.
>
>Your suggestion is exactly what I did as a hack fix. I do it every 25 replacements. The logic is totally flawed however, as some clients have really tiny replacements that this problem never affects (but with the hack in is degrading performance). Some clients have really large replacements and 25 is not enough. Before I go down the avenue of keeping a byte count of the replacements and doing my "select into itself" every 50 meg or so, I wanted to see if anyone had ever heard of such a thing. It's totally freaky!