Ken
Thu Sep 18 14:15:42 CDT 2003
Thanks, Mike.
It looks like GETNEXTMODIFIED() is a big part of what I need.
Ken
On Wed, 17 Sep 2003 22:11:13 GMT, mspratt@losethis.xmission.com (Mike
Pratt) wrote:
>Hi Ken,
>
>Open the Foundation classes in the class browser and look at the
>parent code for the error event of the Ok button. It is specific to
>update conflict errors, but be warned there are some coding errors.
>
>Also you may want to check Doug Hennig's WP on Multi-User and Data
>Buffering issues at
http://www.stonefield.com
>
>HTH,
>
>Mike
>
>On Wed, 17 Sep 2003 15:28:30 -0400, Ken Dibble <kend@stic-cil.org>
>wrote:
>
>>Thanks, Richard.
>>
>>I had read Booth's paper before but I read it again just now. It
>>doesn't really answer my question. Maybe it's just that I'm having
>>trouble generalizing.
>>
>>Let's look at it this way:
>>
>>Suppose I want to use table buffering.
>>
>>Suppose that I want to go through all of the changed records in one
>>table, explicitly present all conflicts to the users, let them decide
>>what to do, and only issue TABLEREVERT() if some user says the changes
>>should not be saved.
>>
>>Therefore, I don't want to quit trying to update records after the
>>first failure with TABLEUPDATE(1).
>>
>>I also don't want to generate an array of failed updates with
>>TABLEUPDATE(2) and go back through them and just revert them all
>>willy-nilly. Nor do I want to keep looping back through such an array,
>>resolving only one conflict at a time, regenerating the array, and
>>looping through it again--if such a thing were even possible.
>>
>>I also don't want to complicate things with transactions.
>>
>>Given these conditions, will the following simplified loop work?
>>
>>DO WHILE TABLEUPDATE(1) = .F.
>> * My conflict resolution method, in very simplified form, does:
>> IF TheChangesAreOK
>> TABLEUPDATE(1,.T.)
>> ELSE
>> TABLEREVERT()
>> ENDIF
>>ENDDO
>>
>>If it won't, can you suggest a solution that does what I want?
>>
>>Thanks very much.
>>
>>Ken Dibble
>>
>>
>>On Wed, 17 Sep 2003 18:12:54 +0200, "Richard Flouriot"
>><r.flourio@wanadoo.fr> wrote:
>>
>>>Hi Ken
>>>You may have a look on James Booth white paper about TABLEUPDATE() At
>>>www.jamesbooth.com
>>>Richard
>>>"Ken Dibble" <kend@stic-cil.org> a écrit dans le message news:
>>>srqgmv0411b9m5gev64eqt6celel2t73t4@4ax.com...
>>>> Up to now I've used optimistic row buffering for multi-user
>>>> applications. Now I'm trying to implement optimistic table buffering
>>>> on the assumption that things will run faster if I don't have to call
>>>> TABLEUPDATE() and check for update conflicts every time I want to move
>>>> the record pointer.
>>>>
>>>> The help says that with CURSORGETPROP("Buffering","Mytable") = 5,
>>>> TABLEUPDATE(.T.) will commit all changed records until it encounters a
>>>> conflict, at which point it will throw an error. I've got a method for
>>>> handling update conflicts that doesn't rely on trapping the error.
>>>> Instead, it kicks in if TABLEUPDATE(.T.) = .F., resolves the conflict,
>>>> and then forces the update. That works fine with row buffering because
>>>> I call TABLEUPDATE() for every row.
>>>>
>>>> It appears that I'm not going to be able to do it this way with table
>>>> buffering because, I assume, calling TABLEREVERT() puts a stop on the
>>>> updating process, possibly leaving remaining rows uncommitted, and
>>>> forcing the update with TABLEUPDATE(.T.,.T.) after resolving a
>>>> conflict on one row would either stop the process or automatically
>>>> force the update on all remaining rows. Am I understanding this
>>>> correctly? Do I need to call TABLEUPDATE(.T.) recursively in a DO
>>>> WHILE loop? Something like:
>>>>
>>>> DO WHILE TABLEUPDATE(.T.) = .F.
>>>> * My conflict resolution method, in very simplified form, does:
>>>> IF TheChangesAreOK
>>>> TABLEUPDATE(.T.,.T.)
>>>> ELSE
>>>> TABLEREVERT()
>>>> ENDIF
>>>> ENDDO
>>>>
>>>> If it's more complicated than that, a sample code snippet would be
>>>> very helpful. I haven't been able to find a clear explanation of what
>>>> to do in this case in the VFP Help or in the books and white papers
>>>> I've read.
>>>>
>>>> Thanks in advance.
>>>>
>>>> Ken Dibble
>>>> Southern Tier Independence Center, Inc.
>>>
>>>
>>>---
>>>Outgoing mail is certified Virus Free.
>>>Checked by AVG anti-virus system (
http://www.grisoft.com).
>>>Version: 6.0.505 / Virus Database: 302 - Release Date: 30/07/2003
>>>