Data separation comes in very handy when you've sent the files to the
client and they call to say;
if I do this, this, and this it doesn't work
and sure enough a script incorrectly sets a field.
Make the change in the screens file and send it off.

In article <1127271660.463870.20070 (AT) g49g2000cwa (DOT) googlegroups.com>, "FP"
<a (AT) pottnerconsulting (DOT) ca> wrote:

Yes, but the client usually says:

"If I do this, this, and this it doesn't work.
Oh, and I also need this, this and this. And six new
fields, another linked table / file and two new reports
... all by last week."

\



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <1127271660.463870.20070 (AT) g49g2000cwa (DOT) googlegroups.com>,
a (AT) pottnerconsulting (DOT) ca says...
A change that minor I'd have just done to their live system by remote
after testing it in the development clone. Its actually less work than
replacing the screens file... and I don't even have to knock everyone
off the server to do it.

In highly customized and/or in-house solutions, (which represents my
environment and experience), in general the changes are either simple
enough to be programmed onto the live system (after testing), or have
implications in field validation/autoenter/security etc that they can't
be isolated to a 'screens' file.

Inversely the problem space that lies between "too complex to be easily
programmed live", yet which consists entirely of "layout and
unpriviledged script" is quite small. Too small to make the 'data
separation' model worth the effort for many systems.

With the new script cut and paste features of FM8, the ability to
migrate small changes from a clone into a live system is even more
reliable and safe. This new reliability has inceased the size of fix I
would feel comfortable retrofitting rather than going through a full
import to new clone -- further diminishing the size of the problem space
that 'data separation' would be best suited for. -- at least in the 'in-
house/highly customized applications' environment.

I, however, agree the shrinkwrap crowd has a lot more to gain from data
separation.

I think the 'data separation' model really shines in 'shrink wrap'
solutions, where you have multiple customers, possibly [ make that
hopefully ]hundreds or thousands -- banging away on the same
solution... at that point if you are lucky enough to have a revision
update that is isolated within the screens file you can distribute a new
screens file and customers can just swap it in and keep going.

-regards,
Dave

There is another upside to data separation.
In the data file you can link tables in whatever way makes the most
sense to get the results of calcs or auto-enters etc.
In the screen file you usually end up with relationships going from
globals to primary keys, you will still need the files to be linked
somewhat the same as in the data file but not to the same complexity.

Having said this, just earlier tonight I had to double check that the
way I get related data in the screens file is the same in the data file
eg.
in screen file the link is
Client - Job - InvItem - Inv and
Client - Client_Inv

in data the link is
Client - Inv

By the way, I don't recommend the above mentioned approach. Despite
the time I waste having to double check things like this, the fact that
I only have about 50 table occurrences in the screens file makes it
MUCH easier to work with scripts.

I will agree with you that data separation causes problems for
security, if everything is in one file you can simply run scripts with
master access. I have to transfer the found set of records from the
screen file to the data file and then operate on them with master
access. I use script parameters to make sure scripts like "Delete All
Records" aren't just run by a user who created his own file and linked
to mine. The problem is the script parameters are transfered between
files which could be a security loop hole. This issue has caused me a
fair amount of time and gray hairs.

Helpful Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:

Which is why the wise developer makes a bunch of extra fields of various
types, before deploying the data files the first time. Generally most
relationship changes will happen in the interface file.

My data files generally have only deletion relationships, and those
involved with lookups. Those types of relationships rarely change.
Everything else, including creation relationships, value lists, portal
management and interface, belong in the interface file, and thus are
easy to upgrade.

The data separation approach does not work 100% of the time, because
clients can be unpredictable. But if it only works 50% or 75%, that's
still a heck of a lot of work saved for the developer.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

In article <1h38fpl.1oyr83z1btv6v2N%lynn (AT) NOT-semiotics (DOT) com>,
lynn (AT) NOT-semiotics (DOT) com (Lynn allen) wrote:

Having anonymous fields doesn't appeal to me. It's often bad enough
trying to keep track of what some fields are for when they have good
descriptive names, let alone something like "FieldA". \

It's similar to the way some people insist on using Repeating fields to
store changeable states for graphic buttons (for example).

Set Field [PrintButton, gPrintButtons -2]

makes less sense than

Set Field [PrintButton, gPrintButtonGhosted]



True *IF* the related file is simply more user entered data, but if it
has to be related to an existing data file you're stuck updating both
(or using your anonymous field names).



From my experience it would be more like 25% (if that much) but then my
clients are just plain stu... err, very nice people. ;o)







Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <220920051240119165%helpful_harry (AT) nom (DOT) de.plume.com>,
helpful_harry (AT) nom (DOT) de.plume.com says...

I agree. I don't care for generic fields either. Especially if I'm on
the receiving end of a project that has them.

Again I agree, and with FM7+ there is no reason to use repeating fields
at all. Just partition this utility junk in a utility table.

In FM6 down, I didn't like repeaters but have to concede that I saw some
merit to one or two repeaters over cluttering up the database with an
extra dozen fields.

Set Field (print, gprint, -2) may be less clear than it could be, but
files with dozens of utility fields gunking up the works was hardly any
better. It was more a case of choosing which of 2 evils you preferred
dealing with.

If I have to put up with anonymous fields I greatly prefer them just
being very simple data entry fields. I do not want them to be
relationship keys, or otherwise used in any complicated way.

I wonder if theres a correlation to the number of bugs. I'd estimate
that most script bugs and all cosmetic deficiencies that I make could be
handled within the 'screens' file, while most 'feature requests' tend to
push into the data file.

So the more mistakes I make the more the data separation approach pays
off... (I didn't intend to make any innuendo here! honest!)

-Dave