Karen - What about creating temp tables for Sales and Payments with
SYS_ROWVER columns and base your form on the temp tables.
INSERT the necessary rows into the temp tables and ON TAB CHANGE, test
for SYS_ROWVER > 0.
You might have to throw in a SAVEROW.
IF SYS_ROWVER > 0, give them a PAUSE msg that says data has been
changed, do they want to update.
If YES, then update the table from the temp table based on the PK and do
your TotalPayments calcs; if No, reload the temp table from the main
table to get the original data. This won't say which column has been
changed, but at least it'll give them a chance to trap inadvertent changes.
Creating the TempTable:
PROPERTY TABLE TempTable 'CLOSE'
SET AUTOROWVER ON
SET ERROR MESSAGE 2038 OFF
DROP TABLE TempTable
SET ERROR MESSAGE 2038 ON
CREATE TEMP TABLE `TempTable` +
(
TempTable Def
)
PROPERTY TABLE TempTable 'OPEN'
SET AUTOROWVER OFF
RETURN
I'm sure there are pitfalls, esp in multi user - different users working
on the same row could clobber each others data.
Doug
On 8/25/2015 9:32 AM, Karen Tellef wrote:
My dilemna: very old (1980s) RBase database, designed by someone
other than me. Not very relational in that there is a Sales table and
a Payments table, but there is a column called TotalPayments in the
Sales table that has a total of the payments so that a computed column
Balance can be calculated.
In the DOS system, there is a separate form for Payments, so on
closing that form it's very easy to compute the total payments and
update the Sales table before bringing the Sales form back up.
In 9.5, they LOVE the idea of a form with multiple tabs, so I have
Sales on tab 1, and Payments on tab 2.
Here's what works: If you're in Payments, I have an "on row save" eep
so that if they change the amount it sums the payments, updates the
Sales table and refreshes the Sales table. So if you save the row and
then click back into tab 1, viola it's there.
What doesn't work: If you change a Payment amount and, while still
in that row, click to tab 1, your row is not yet saved so nothing has
been changed. I can see that if I then physically click into a Sales
field on tab 1, it then saves my payments and does a refresh. But
just clicking on the tab 1 header does not save the data.
I tried putting identical code in the "on leave section" of
Payments, but that does not evaluate if you click to another tab or
even if you [esc] out of the form.
I know I can do something like trap the payment going into the field,
trap it going out of the field, and if it's different than do a
"saverow", but that takes away the ability of the user to change their
mind about the change.
What I also tried: I can do a "change tab eep" on tab 1 so that it
puts focus into a Sales field. That works cuz it forces a save. Only
issue is that this client worries about people making inadvertent
changes so they don't want them put "into" the data unless they
click. So unless I add a "dummy" field into the table.....
Any other ideas?
Karen
