fpxfer export to a file - permissions/ownership

[Richard Kreiss]

Mark,

>From a purely theoretical point of view, you are correct in everything you
say. 

However, from a practical side, most of the time it is a business that is
having the problem and in most cases the owners or managers want the problem
fixed quickly and/or eliminated.  This leave those in charge of the database
( any database) with a problem, do we look for where the problem is coming
from and not correct the problem until we know where the problem is or do we
make the "quick Fix" and then look for where the issue is coming from?

If the issue is endemic in the software which is outside the control of the
staff, then all they can do is report the problem to the vendor and make use
of any easy fixes available to keep the program running.

I have had a client complain the a program that had been working fine for a
few years is now not working properly.  As I do not manage the operating
system, when I checked, the company managing the OS had changed permissions
(Windows) for accessing some folders(directories) which some reports were
written to.  I had to address this issue and the owner/CEO advised that
company not to change any access permissions without checking with me first.

I have been using filePro long enough to know that the *nix systems have had
an ongoing problem with permissions.  However, some of this may be an issue
with the filePro install and others times with those administering the OS
,making changes without checking with the database people.  In this case,
using the setperms script will correct the situation quickly.

As for rebuilding the automatic indexes using dxmaint filename -ra -e, yes
this is a crutch that has been around a long time.  The issue then is how
best to handle index issues.  I have lived with this issue for over 30 years
now.  First on Unix systems and then on networks or Citrix Multiuser.
Sometimes the problem was caused by users disconnecting improperly; other
times is was bad sectors on a hard drive, and lastly poor programming on my
part.  I was able to correct the poor programming but had little control
over bad sectors on the hard drive and I had to leave it to management to
insure their employees followed proper procedure for logging out of the
system.  

I have had an ongoing disagreement with Ken Brody over the best way to
rebuild a problematic index.  Most people would just run dxmaint from the
developers menu and rebuild the index.  Ken has always said that the index
is deleted and the file size is zero.  Anecdotally, I found that deleting
the file from the OS and the recreating the index eliminated the issue.  

The one issue you did not mention was filePro's free chain.  One of my
clients was having an issue with free chain for one file which has over 200
million records and grows at a rate of between 3-5 thousand records a day (6
days a week).  This same file has almost about 10,000 records deleted each
week.  Since upgrading them to 5.8, this issue has almost disappeared.  

As for running dxmaint at night, they do this three times a week, late at
night.   That order detail file takes almost 1 1/2 hours to rebuild the 3
primary automatic indexes.  These are multi key indexes.  Being down for
this amount of time is very costly to them.  

I would like to put it another way, running dxmaint at night is like doing
preventive maintenance on a car or a computer.  One does this to prevent
problems before they become a bigger problem.  This does not mean one should
not look for where the problem is coming from.  However sometimes it is
outside one's ability to correct the issue and therefore must work around
the problem.  

This is not just a filePro issue but one of most programs have otherwise no
company would release maintenance releases.  Think about the number of
updates to the various apps that people have on their smartphones.

Just a point about filePro, I have clients who have been running an
application I wrote almost 30 years ago with 4.0/4.5 or 4.8 and they have
not upgraded it since it was installed.  This was a DOS based application
now being run on Windows 7 or Windows 10 without issue.  The only time I
hear from them is when they need a new printer or want to move the program
to a new server or computer.  They really don't have an issues with the
program and I am not making any money in support.  All of these clients
rather pay me a higher per-diem rate then take a support contract.  I am not
sure that other database companies can say their old DOS based program
continue to work with today's operating systems.

One issue I do have with filePro is not knowing what functions are or will
be effected by the increased speed of systems.  I did run into this problem
a few years ago and had to modify some programming to avoid the issue.  It
was a simple matter of adding a drop to a browse lookup.  


Richard Kreiss
GCC Consulting


> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Fairlight
via
> Filepro-list
> Sent: Saturday, September 16, 2017 2:18 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: fpxfer export to a file - permissions/ownership
> 
> On Sat, Sep 16, 2017 at 01:06:55AM -0400, Laura Brody via Filepro-list
thus
> spoke:
> > Writing the setperms script was one of my better ideas. I can't begin
> > to
> 
> It's a curse and a blessing.  More curse than blessing, IMNSHO.
> 
> Permissions should never 'accidentally' get whacked.  If someone is
whacking
> them, they should be forced to find the root cause.  The only time some
people
> learn is when they're forced to pay for something, be it financially or in
time
> spent.
> 
> Having a crutch to rely upon to quick-'fix' the permissions is thus more
harm
> than good, in the long run.  It encourages people to do things they
shouldn't be
> doing.
> 
> Sure, it's convenient, but at the cost of learning to do things the proper
way,
> because there's zero incentive with that crutch readily accessible.
> 
> Automation is supposed to be reserved for handling -necessary- repetitive
tasks.
> Fixing file permissions which should never unintentionally be altered is
neither
> something which should be repetitive, nor something which should be
> necessary.
> 
> The next worst offender in the filePro world is -ra on dxmaint.  I know
people
> who rebuild their indexes every night via cron, whether they need to or
not.  This
> should never have been allowed to become 'a thing'.
> The company should have been forced to fix the index problems which
> necessitated it in the first place, long before this became a habit for a
lot of
> people.
> 
> At least in the case of indexes, it wasn't users' faults.  The same can't
be said of
> file permissions changing.
> 
> If you go back to the old saying about giving a man a fish versus teaching
a man
> to fish, setperms is 'teaching' a man how to 'fish' with a twenty
megatonne
> tactical nuke.  It might do the job, but in the end it's really not a good
practise.
> 
> mark->
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list