G'day Karen, At 16:32 19/11/02 -0500, you wrote:
>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. I'm not sure that this is a 'new bug'.
I have not had a problem with this until now but... Thursday last all was working well. I downloaded Friday's patch and tried it again with the same non-optimum results. I reverted to 1.851, backed up the database, restored the backup, renamed the database and reloaded back to the original name. I then went to a form displaying a list of bills (accounts payable), clicked a button to disburse one. This creates a new transaction in TranHeader and TranDetail, displays the new transaction in a form and on exit returns to the list of bills. What should happen is the date disbursed should be updated in the record for the account payable. It obviously doesn't display in the list form until it is refreshed so I [F7] then [F8] to display the updated data. It was not updated. So I clicked on the [Go To] button to display the edit form, manually entered the date disbursed and returned to the list form, [F7] then [F8] to display the updated data and the date disbursed field was blank. It had been overwritten by the return to the list form. I exiting R:BASE, went back in and repeated the steps in the last paragraph and this time the edit was saved.
Seems to me like the same 'old problem'. The problem being one form calling up another form based on the same table. Is that what you're doing?
Exactly.
Exiting the first form will ALWAYS overwrite changes made to the data made by the 'lower' forms.
The edits performed in the lower table are being overwritten but inconsistently, sometimes they are, sometimes they aren't.
So how do you allow the user to browse a list form of all peopleIt's been that way since I can remember. I don't even bother with RECALC or NEXTTAB or PGDN, none of those tricks. I just make it a rule that if a 'subform' is based on the same table, then I exit the first form, bring up the subform, then bring the first form back up again.
to be called today, go into sub-forms, edit the person record,
come out, proceed to the next record and so on? Closing the
first form then redisplaying it would always take the cursor back
to the top record in the where clause, which could be hundreds of
records from where they went to another form.
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/
