Kent, Regarding the "Seek", what key are you doing the Seek on or are you using record numbers to access the records. If so then this is the problem as when records are added to a table using buffering they are allocated a "temporary" record number which is negative to indicate that the record is still buffered. Only when it is committed will the record number be correct soI'd look at this first. Have you any more information on how you are seeking the record as this would help.
On the disappearing changes, you must be trying to write the record back on computer 2 so you want to really remove whatever feature is trying to update the record. How are you displaying the records eg a grid or bount textboxes etc. If it is grids then any updating of fields in the grid (tabbing along a record and firing the Validation or Lostfocus events for the textbox in each column) will actually force an AfterRowColChange() event to fire which effectively writes the data back to disk so this could be the problem as computer 1 has already updated the record - hence the conflict. In which case make sure that these events don't fire. Dave Crozier The secret to staying young is to live honestly, eat slowly, and to lie about your age -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kent Belan Sent: 31 July 2006 18:43 To: ProFox Email List Subject: RE: Buffering and TableUpdate() Hello Dave, Thanks for your help, I am getting closer to solving this problem. I now have a timer on the form that refreshes the data by way of seek. All fields on the form are form properties that are displayed only. All edits are done on sub forms with locking enabled. I still have a couple of problems ... If I am on the same invoice on both computers and make a change on computer 1, the change now displays on computer 2 via the timer seek and form refresh(). However sometimes the seek command returns not found() even though the invoice is there. What would make the seek report not found() ? Also, sometimes if I make a change on computer 1 then when I exit the application on computer 2 I get a message "Update conflict in cursor Invoice" with an OK / Revert / Help buttons. Thanks again for your help, Kent > > Kent, > Re-seeking the invoice data will give the desired effect or even a > "goto recno()" for individual records in the invoice. > > Just a point, if you are viewing the invoice details in a Grid then > you certainly need the "set refresh to" set to say 1 second. > > How are you holding the data on your forms? Are the data fields bound > directly to the table data or to the fields in a cursor or data object > and are you using any form of transactions? If not then it might be > sensible to look a this form of processing so that all the updates can > be made in effect "off line" without affecting the underlying data > until you "commit" or "rollback". > > Personally in a strictly ON-LINE system I hold all detail data in a > grid and that way it gets refreshed automatically regardless of > refreshing the page. > Once the "Edit" selection is made for an invoice, the header is "locked" > using RLock() so that nobody else can edit the record and Double > clicking on an item opens up a edit section of the form for that item > in the knowledge that nobody else can be editing the Invoice at that > time. When I'm writing an OFF-LINE system I use the temporary cursor > approach to load ALL the invoice data for modification then commit the > changes back when apropriate. > The nice thing about doing it this way is that the user can always > easily ABORT. Although you can do this on a live underlying table > using "Begin Transaction" I find it messy, hence the Off-Line approach > with data being loaded into data objects from the cursor. > > There are advantages in using each method and implimentation is > normally down to personal preference. > > Just remember that you WON'T see the updated data untill the other > machine commits the transaction or moves off the record(s) (with No > Buffering) or commits the update (with buffering) no matter which > method of refreshing you use, So if the "new record" form sits on an > item line it will NEVER get written back to the underlying table. > > Dave Crozier > The secret to staying young is to live honestly, eat slowly, and to > lie about your age > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
