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 > > _______________________________________________ Post Messages to: ProFox@leafe.com 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.
