qualifier

[Brian K. White]

Such a script really wants several things to handle several different common 
needs.

I have a few different scripts, each geared towards slightly different 
needs, and each written differently, all somewhat too full of assumptions 
about the way I do things to be generally useful, since the needs are simple 
enough at last half or more of this list could write such a script or 
something similar directly in fp.

But a couple ideas I think might be useful to ponder while we collectively 
create something or looking over whatever we each do now.

* I treat the unqualified dataset as code. There is data in there that is 
common to all qualifiers. I don't mean like a common set of customers, or 
even gl account numbers or names, but various things that might otherwise be 
done in the form of hard code and listboxes. like types of things (what type 
of trailer: flatbed, refrigerated, 50 others..., ), a couple different 
special purpose zip-code databases, etc.

* I have put a file named .common in several filepro file directories, which 
my various copy/create/delete/rsync scripts look for to tell them how to 
treat a given file. When copying a qualifier to a new qualifier, the script 
knows to just skip right over a file with .common in it. Most of the files 
with common data such as the zipcodes and trailer-types above, the data is 
in the unqualified and the code all has lookup @, and real qualifiers never 
want a key/data/index in that file.

Since we happen to treat unqualified dataset as code now, and since I do 
have a copy-qualifier script, which recognizes .common, thats how I create 
new qualifiers by just copying the unqualified to a new qualifier. 
Techincally, for the same reason several files have no data or indexes 
except in unqualified or a few other oddball special-purpose quals, I guess 
many of the files should conversely have no data or indexes in the 
unqualified, but they all do and so I just use it.

And there are other needs and behaviours that are appropriate in other 
situations.
creating a new qualifier in an existing system is one thing. Creating a new 
system from an existing system, without either zeroing out all data or 
copying all data, and without copying all existing qualifiers except for 
unqualified and maybe one existing qual, or making a new empty qual along 
the way, is another thing. Similar in the need to handle the data 
differently in the different files, but different in that you want to copy 
all the code as well as data.

The .common thing doesn't handle everything of course. Various other special 
purpose qualifiers have popped up that should be handled differently than 
either what I call a real qual (normal user data) or unqualified. I'm 
thinking of maybe enhancing the idea so that .common may optionally contain 
a list of qualifiers, perhaps with some kind of how_to_handle code next to 
each, so that if .common exists, the file is handled as above. If .common 
contains one or more lines of ".common syntax" whatever that will be, then 
in addition to the main new qualifier, those qualifiers are also handled 
however indicated along the way. Maybe treated as code and copied (as the 
same qualifier in some new fp tree or remote host), or created new and empty 
(as the same qual in a new fp tree or remote host). Or copied or created new 
empty to a new name that goes along with the new overall target qualifier. 
Like if you are creating or copying <qual> then you also need to create or 
copy <qual>_log maybe.

I don't think there can be a simple script that does your whole fp tree that 
will actually work for most people. But a simple script that had some 
options, which worked on one or a specified list of files is possible. Then 
to do your whole tree you run that script from some other script that 
somehow knows what kind of rules to follow for each of your files, like the 
.common thing or a better version of that that handles more situations. Or 
maybe a filepro process where the knowledge of how to treat each file is 
config data stord in a fp file.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!


----- Original Message ----- 
From: "Jean-Pierre A. Radley" <appl at jpr.com>
To: "FilePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Wednesday, August 01, 2007 8:16 PM
Subject: Re: qualifier


> Jose Lerebours propounded (on Tue, Jul 31, 2007 at 06:48:26PM -0700):
> | JP posted,
> |
> | > So far as I know, the only way to add qualified files is to run 
> ddefine
> | > for each database.
> | >
> | > When there are more that a handful of them, this gets real tiring.
> | >
> | > Has anyone concocted a script to add a qualifier to every database?
> |
> | http://www.fpgroups.com/index.php?Target=code
> |
> | Please let me know if you find this script useful.
>
> I don't know who wrote that script, but please tell him or her that it's
> really not very useful, because
>
> 1) It limits a new qualifier to three characters, instead of
>     filePro's limit of seven.
>
> 2) It *duplicates* the base unqualified files, with all of their
>    existing data.  Maybe somebody might want that once in a blue
>    moon, but when one adds a new qualifier, should one expect it
>    to come with records already present?
> -- 
> JP
> ==> http://www.frappr.com/cusm <==
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>