Hi, Marc!

I said nothing again transaction. Moreover, I underscored that it's just a feeling. I think that I'm pretty happy with things I use now, I also rely on RLOCK()/UNLOCK.

>Ed,
>
>I will have to disagree with you here. I've used Transaction management and it works. I think you have to have buffering on, I know you have to have a .dbc.
>
>I BEGIN TRANSACTION at save time, and raise a ROLLBACK if anything goes wrong. I rely on the RLOCK/UNLOCK (with somewhat less succes since today, see my thread about unloc) to prevent simultaneous updates.
>
>Feels good to post positive :). Should try this more often.
>
>Marc
>
>
>
>
>
>>Hi, Jim.
>>
>>I always felt that something is not guaranteed in Transaction+Bufering. Just a feeling, nothing else:).
>>
>>>Hi Steve,
>>>
>>>Can you try the program after (temporarily) removing the TRANSACTION business?
>>>
>>>I saw nothing in the Help restricting TRANSACTION processing to BUFFERED stuff, but as we know from other omissions in Help, it might well turn out to bre such.
>>>
>>>I agree that it is perplexing. Do you perchance "play" with the MULTILOCKS setting at all - it will do an implicit UNLOCK ALL if manipulated after some LOCK(s) have been set.
>>>
>>>Good Luck,
>>>
>>>Jim N
>>>
>>>>Hi Marc,
>>>>
>>>>Thanks for coming in. Correct, the key here should be found as it was obtained elsewhere so is known to exist. I thought the same thing and threw in an
>>>>IF SEEK() with the same results.
>>>>
>>>>Regarding transactions, does not BEGIN TRANSACTION create it's own buffered area? Wouldn't END TRANSACTION flush that buffer and ROLLBACK discard it without the table/view itself was buffered? If one is using class properties to map to a form, does it make sense to use table/view buffering?
>>>>
>>>>Steve
>>>>
>>>>>Hi Stephen,
>>>>>
>>>>>Just as an aside, you do not test the seek. Maybe it failed.
>>>>>
>>>>>A second question is that you need buffering in order to use transaction management do you not?
>>>>>
>>>>>And finally, locking seems to be out of fashion. :)
>>>>>
>>>>>Marc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Jim,
>>>>>>
>>>>>>Yes, old fashioned buffering. None in use. The updates are embedded within a transaction but that's neither here nor there at the moment. The network is Banyan which I'm told is to become NT after the 1st of the year. My local testing is using Win95 starting the app twice as two different users.
>>>>>>
>>>>>>And I don't think your dyslexic......but yes, the seek is before the rlock().
>>>>>>The control sources for the form are properties of a class and not directly bound to a table or view. The underlying record should still get locked while a user manipulates the data.
>>>>>>
>>>>>>There are up to 6 forms on display, each with it's own private datasession. I've found in the past that locks are not respected sometimes between private datasessions although the help says that they are supposed to be.
>>>>>>
>>>>>>Master form - Parent
>>>>>> Child form - could be up to 5 different separate forms
>>>>>>
>>>>>>A parent is retrieved and a single lock attempted. Even with this form up and the record locked by user 1, RLOCK returns .T. There could be > 1 children for each of the 2nd tier child forms, and an attempt is made to lock each of the children even though only one is on display.
>>>>>>
>>>>>>Maybe buffering is required here but I wouldn't think that this should be the case as 2.6 never had it.
>>>>>>
>>>>>>SQL commands are used to insert/update/delete records from class properties to the table and there are various "trigger" updates although only delete triggers are in the database. I've noticed that if a change is made in the parent form that must update the child records, all 6 datasessions must be accessed and have an unlock all issued just prior to the update commands otherwise the SQL update fails which implies that record locks are not recognized across private datasessions. I recall answering a post here to this effect about a month ago.
>>>>>>
>>>>>>Anyway, this is perplexing.
>>>>>>
>>>>>>Thanks,
>>>>>>Steve