Dorris,

Don't know if this applies here, but in the MS NewsGroup some have a recognized problem (no fix yet) with updates being missed when using TABLEUPDATE with TRANSACTIONing. They have also *NOT* mentioned Memo fields.
They have, however, noted that the situation seems to happen when the file header gets into a certain state and some thing that a PACK seems to clear the situation.

In any case, they do something in their code which I feel *should* be different. They all seem to code:

INSERT INTO. . .
Begin TRANSACTION
TABLEUPDATE(.T.,.T.)
End TRANSACTION
- TABLEUPDATE reports .T. but update is gone!

I feel that this would be a more "correct" coding sequence if the "INSERT INTO. . ." was *inside* the Begin/End TRANSACTION.

Anyways,
good luck with it (and I doubt that changing to a 50 byte field will make much difference),
Jim N.

>>>Hi all.....got another one of those questions.
>>>
>>>Seems that VFP is being selective about saving memos. It SAYS it saved it, it ACTS like it saved it, until you exit the system and look at the actual table. This is a VFP3.0 system running on Novell 3.x/4.x netware and Win 3.11. Any ideas?
>>>
>>>Oh, did I mention that this behaviour is sporatic?
>>
>>Dorris, just to double check...
>>Are you using buffering? You may need to issue an explicit TABLEUPDATE()
>
>I am and I do. VFP does the tableupdate() and returns that it saved with no problems. As I said, this behaviour is sporatic and I'm about ready to convert the bleedin' memo to a 50 character field and tell them if they need more than that, they're being WAY to wordy!