The button in question isn't updating other files; its only updating
the SigId in the job file. There are two relationships between the
parent (job) and the grand parent (the colors) files, which is defined
as Job.SigId + '1' = SigColor.SigId + SigColor.SideId (for portal C)
and Job.SigId + '2' = SigColor.SigId + SigColor.SideId (for portal D).

So when the SigId on job changes, the records displayed in portals C
and D change. The problem only exists though when the record in portal
B has not been committed; it seems that the Commit wants to save the
portal records in C & D before the new record and B, thus everything
blows up.

There's much more than these few files that would be replaced by the
..Net app.

Some reasons include lack of transaction support (and we will likely be
requiring distrubted transactions in the near future), the business
logic, database and UI seem hopelessly intertwined, there's no way to
build automated unit tests to ensure that changes we make do not break
other functionality, lack of rich user controls, lack of control over
record locking (by this i mean the ability for one user to 'kick out'
another user thats viewing the record). To close the list, I think
what I'm trying to do should be trivial (a form displaying a record, a
list of all child records, and then when a child record is selected
displaying only its child records), but for some reason requires alot
of effort in FM.

One thing we really want to implement is field-level auditing, so that
we know exactly who changed what. This will become more important if
(more likely when) we allow our customers to modify their jobs over an
extranet.

So, there's a subset of the reasons we have. Again, I do appreciate
your help on this; 7 does offer substancial improvements that will make
working in FM easier, as well as some performance gains. I'll be happy
to leave 6 behind forever.

Andy