Tom, > So the data _is_ being correctly saved to the tables by the > edit form. I confirmed this by opening another instance of > R:BASE and viewing the post edit data after exiting the edit > form and prior to exiting the View form and returning to the > list form where it is overwritten. > > The list form is overwriting changes made to the data in the > lower forms. I tried changing the properties of the list form > to make it totally non-editable to no avail.
If I get this right, the form where you started (the list form) is overwriting data changed in subsequent forms? Since the first form is in edit mode I wonder if the list form is simply "Saving" what is on the form _w/o_ a dirty form que, which might explain the change in functionality? You might try a SaveRow in your eep just prior to use of the subsequent forms... Ben Petersen > G'day Karen and Alastair, > > First let me say thanks for the confirmation of the bug and > I appreciate the assistance of my fellow list members. > > At 09:27 19/11/02 -0500, you wrote: > >This jogged something in my memory with an app that David Blocker and > >I were working on. An eep would select data from a table into > >variables and do alot of processing. We needed to trap later on in > >the eep whether another user had made any changes to data in that > >other table since the time that the eep was started, so another > >select was done. Even if another user made changes while user#1 was > >still in the eep, the second select would usually (not always) bring > >up the original data. We asked RBTI why it was doing this, and were > >told that the old data was still in my cache so it grabbed it from > >there rather than going out to the table again. In order to 'force' > >the cache to be refreshed, we were told to do a bogus update to that > >table (like: Set TextCol = TextCol where record = <the record you're > >looking for>) right before that second select. Fixed the problem, > >but that always bothered me... I think the reason it didn't behave > >that way all the time is that sometimes the cache must have been > >flushed or filled up, or whatever, to cause it to lose that first > >select. > > Unfortunately this won't solve my problem. > > I have tested the following scenario. > > I have a form that displays a list of bills in a region. > At the top of the form is a [View] button which displays > a two table form in which to view the entire bill record. > On the View form there is an [Edit] button which displays > a copy of the [View] form with the data editable. > > R:BASE crashed half way through entering a new bill record > so I needed to go in and enter the detail section and update > the header for the bill. > > I went to the list form and clicked on the [View] button, > then clicked on the [Edit] button on the view form, > made the changes in the edit form, > exited to the view form, > pressed [F8] to refresh the data and observed that the record > had, in fact, been saved with the amended data, > but when I went back to the list form the header data had > reverted to the pre-edit version. > > So the data _is_ being correctly saved to the tables by the > edit form. I confirmed this by opening another instance of > R:BASE and viewing the post edit data after exiting the edit > form and prior to exiting the View form and returning to the > list form where it is overwritten. > > The list form is overwriting changes made to the data in the > lower forms. I tried changing the properties of the list form > to make it totally non-editable to no avail. > > This is a new bug recently introduced in the latest beta as > this procedure is used (and has been successfully for several > years) in numerous places in BizMan. > > It is a vastly superior technique efficiency wise than requiring > the user to enter a specific record ID from a menu structure for > every time they wish to edit a record. Which is the clumsy, > kludgy "work around" to which I have had to resort in the short > term. > > Warmest regards, > > > Tom Grimshaw > coy: Just For You Software > tel: 612 9552 3311 > fax: 612 9566 2164 > mobile: 0414 675 903 > > post: PO Box 470 Glebe NSW 2037 Australia > street: 3/66 Wentworth Park Rd Glebe NSW 2037 > > email: [EMAIL PROTECTED] > web: www.just4usoftware.com.au > > "... the control of impulse -- is the first principle of > civilization."-- Will Durant, Pulitzer Prize winning philosopher, > writer and historian > > the most needed product in the world can be found at > www.thewaytohappiness.org > > This email and any files transmitted with it are confidential to the > intended recipient and may be privileged. If you have received this > email inadvertently or you are not the intended recipient, you may not > disseminate, distribute, copy or in any way rely on it. Further, you > should notify the sender immediately and delete the email from your > computer. Whilst we have taken precautions to alert us to the presence > of computer viruses, we cannot guarantee that this email and any files > transmitted with it are free from such viruses. > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In > the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
