Marc,

Just so you know, I typically use buffering and my transaction class is setup to handle whether the transaction involves buffered tables/views or not. This one app in particular was requesting a lock and to shut down the form for user #2 so that there was no question that the record was locked by user #1. This certainly left out optimistic buffering and we also know that the issue with pessimistic is that user #1 must actually alter a buffer before the lock takes place. That's how this whole RLOCK() mess came about.

I had been quite familiar with transaction processing from good ol' COBOL work where I was using a Digital transaction mgr. When VFP came out with transaction processing I thought that was great but even then, I don't recall any documentation indicating that buffering was required. I'm sure that you'll start implementing transaction processing whether you're using buffering or not. I find it quite nice.

I appreciate your assistance here.

Steve

>Errr, Stephen, you I think you are right.... I did a few simple tests and it seems you _can_ use transaction management without activating buffering.
>
>I looked at the examples in the manual, and to my shame I have to admit that they almost univoqually confirm this. How I inferred that I had to implement buffering is beyond me.
>
>Goes to show ...
>
>Anyway, thank you for drawing my attention to this.
>
>Marc
>
>
>
>
>
>
>>>>>
>>>>>
>>>>Marc,
>>>>
>>>>I agree that you need the dbc, which is there and I have a transaction class that is handling that job. Like you, it does a rollback if an error occurs. I've found it to work without buffering on the tables though. I can only say that I know this because if an error happens, the updates do not take place. I have not done rigorous testing of it.
>>>>
>>>>Steve
>>>
>>>Steve,
>>>
>>>That is interesting. But I'm not sure you are right, because I do not need buffering for my purposes at all, since like you my users do not modify the database directly. Where you use properties, I use a cursor, but I think that does not change a lot. Since I do a lot of one to many input with grids, it seemed more natural to me to use cursors.
>>>
>>>It may me a weird argument but at the time I conceived my system, I would not have installed buffering if I did not need it, and I guess I did because of my reliance on transaction management.
>>>
>>>Kind regards,
>>>
>>>Marc
>>
>>This is an example of transaction usage apparently without buffering from the help section for VFP 6.0. Although many references are made to the use of buffering and =TableUpdate, this example indicates to me that it may not be necessary. But then again, this is M$ documentation and who knows. But, I have noted when crashes occur while developing, the data is not saved to disk.
>>***********************
>>Notice in the following example that because changes in a nested transaction aren't written to disk but to the transaction buffer, the inner transaction will overwrite the changes made to the same STATUS fields in the earlier transaction:
>>
>>BEGIN TRANSACTION && transaction 1
>> UPDATE EMPLOYEE ; && first change
>> SET STATUS = "Contract" ;
>> WHERE EMPID BETWEEN 9001 AND 10000
>> BEGIN TRANSACTION && transaction 2
>> UPDATE EMPLOYEE ;
>> SET STATUS = "Exempt" ;
>> WHERE HIREDATE > {^1998-01-01} && overwrites
>> END TRANSACTION && transaction 2
>>END TRANSACTION && transaction 1
>>
>>Thanks,
>>Steve