G'day Tom: I have run into problems when I update from a lower form and the top form does not update. I have tried RECALC VARIABLES, RECALC TABLES with no luck as these commands apparently update variables but not necessarily columns. I have gone back to my old stand by procedure of adding: SAVEROW NEXTROW PREVROW on the EEP just before you return to your top form; which in effect updates (refreshes) the display on the top form. You could add some code to check if you are in the last row after NEXTREC and if this is the case skip the PREVROW command (check for error code). You may also want to try changing the setting on the REFRESH parameter. SET REFRESH specifies how often R:BASE refreshes a form or the Data Browser, and displays current data. It also automatically recalculates lower tables in forms. Specify zero to turn the setting off. When REFRESH is set off, R:BASE tells you of edits when you save or delete a row. I believe that the default setting for this variable is 0, which means that refresh is off. I don't know if this will help you, but it is worth a try. Javier
Javier Valencia, PE President Valencia Technology Group, L.L.C. 14315 S. Twilight Ln., Suite #14 Olathe, KS 66062-4571 (913)829-0888 (913)649-2904 FAX -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Grimshaw Sent: Tuesday, November 19, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: Re: Heads Up - Razzak's Reply 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/
