Hi Brad,
My 2¢:
- It's possible to write validation rules to check whether certain
fields have a value in them and whether another table has a related
value, so FileMaker won't allow “bad” data in the table. The way it
does this is not especially elegant, but this is very easy to
implement, so value for money is still high, in my opinion :)
- Another way would be to allow “bad” data in the database, but
separate “good” data from “bad”. I mean, make a field to indicate
this and set it to recalculate when any of critical fields are
modified (with auto-enter such a field can use related data and
remain stored). Later we can use this field to boldly show the record
status to the user and also check it in all operations we need that
data integrity for. E.g. if the user tries to print an address label,
but the address is incomplete, the system refuses to do this and
displays a message why.
Kind regards,
--
Mikhail Edoshin
Information Analyst
Skeleton Key
[EMAIL PROTECTED]
On May 17, 2008, at 6:09 PM, Brad Lowry wrote:
Hi All,
This will sound like a rant, but before I begin I would like to say
that I would *love* to be shown my ignorance and corrected that the
"Unrealized Feature" I write about is indeed "improperly
implemented" on my part.
So this whole thing where you can set a layout not to Commit
Automatically -- wha-hoo! This was supposed to free me from the FM6
(and prior) Kludge that many of us used to use:
FM6 Kludge:
So I want to have the end user enter First, Last and Zip for new
Clients. But I don't trust end users to use "New Record" since the
data integrity was atrocious. So I create the global fields gFirst,
gLast and gZip. I place them all on a layout. For the "New Client"
button I clear them all and go to that layout, when the end user
clicks "Post" it validates that the fields are all non-empty and
that the Zip Code has a related record in my Zip Codes table -> if
the validation passes, a new record is created and the First, Last
and Zip fields are set with the values in gFirst, gLast and gZip
respectively and the City and State fields are setaccording to gZip
and the script returns to the previous layout -> else a validation
failure message is displayed and the script halts. Alternately, if
the end user clicks "Canx" then the three global fields are cleared
and the script returns to the previous layout. (And for the "Edit
Client" button the process is essentially the same only the globals
are filled with the current record's values and post does not
create a new record.) (Essentially using a bunch of globals to
create a pseudo object and using ORM techniques).
FM9 -- The Promise!
The promise of the ability to set a layout to NOT automatically
commit was that this Kludge would be unnecessary. Until the end
user clicked "Post" the changes were not made, and the new window
could either be a current record or a new record -- and the New
Record didn't "take" unless it was committed (but the serial id was
incremented annoyingly -- but I quibble).
FM9 -- The Reality...
Although you can attach logic to a Post and a Canx button that
would do what you wanted with the FM6 Kludge, if the end user
happens to click outside of a field she/he will be prompted whether
or not to Save Changes to the record -- An Esoteric prompt that
completely obliterates the attempt to make Adding Records immune
from unsophisticated end user mischief. And! If the end user (as
one would normally do) clicks "Save" and then upon clicking "Canx"
the record exists and none of the scripted validation was applied.
FM9 -- I hope I am wrong...
Please, I hope that someone can correct me. I hope there is a
strategy the emulates the FM6 Kludge that I am failing to see.
Otherwise, I am going to revert to the Kludge to get my robust Date
Entry/Edit with robust Validation strategy implemented.
FM10 -- How about a true Object? (or a "Holder Record" if FM wants
to protect the end user from scary IT words)
You can set a layout to be a "holder" layout, where without
"CommitHolderRecord" everything about the record (the empty values
for new or the edited values for existing) are lost. You could have
"GetHolderRecord[new]" and "GetHolderRecord[current]" to work with
"CommitHolderRecord[new]" and "CommitHolderRecord
[current]" (respectively, except that Get[current] could work with
Commit[new] for a Duplicate routine). All scripts run for fields
for a Holder Layout apply to the Holder Record only, and only upon
Commit are all auto-entry values set (espeically the Serial ID) and
the Holder record is then Dropped. (Of course, there would be an
exlicit "DropHolderRecord" script step as well.) All actions for
any Holder Layout have no effect (and throw an error) without a
Holder Record being instantiated. All the pieces are there for FM
to create this from what it already allows ($$globals on the fly
and all).
I am looking forward to being shown my error?...
--
Sincerely,
Brad
