enter creation password when lookup with qualifiers?

[Bruce Easton]

Nancy Palmquist wrote Tuesday, January 29, 2008 5:08 PM:
> 
> Bruce Easton wrote:
> > Kenneth Brody wrote Tuesday, January 29, 2008 10:46 AM:
> >> Quoting Scott Nelson (Tue, 29 Jan 2008 07:36:15 -0800):
> >>
> >>> Kenneth Brody wrote:
> >>>> Quoting Scott Nelson (Mon, 28 Jan 2008 17:32:29 -0800):
> >>>>
> >>>>> Is it normal for the 'enter creation password for filename' 
> >> prompt when
> >>>>> doing a lookup using a qualifier?
> >>>> Assuming you mean at runtime, the answer is "no".
> >>>>
> >>>> It is, however, normal for it to appear at runtime when using 
> >> a variable
> >>>> for the filename.
> >>>>
> >>> That is it.  But why if there is a variable????
> >> ky = "myself"
> >> fn = "employees"
> >> lookup salary = (fn) k=ky i=a -nxp
> >> salary[10] = salary[10] * "1.5"
> >> write salary
> >>
> >> -- 
> >> KenBrody at BestWeb dot net
> > 
> > I went off on this some time ago.  I understand the security 
> > advantage this gives an application.  And I understand how 
> > this came in to being historically, and in that light, the 
> > behavior seems consistent with filepro.  But I still feel it 
> > was a big mistake to bring something called a "creation password" 
> > to any runtime program in this way.  I feel for many types of 
> > applications, it is unrealistic, unfriendly, unappliable, 
> > to have end-users responsible for entering a creation password 
> > at runtime for something that indicates that it is protecting 
> > the developer. 
> > 
> > So not only is it expressed poorly in this case when it is 
> > encountered, but a password protection scheme is now 
> > unilaterally imposed (upon perhaps a large organization) 
> > where the only goal of the developer was to protect his/her 
> > work.
> > 
> > Of course we are left with two options - don't use any 
> > variable filenames when you want to creation-password protect 
> > your work, or don't use creation-passwords.  Big impact on 
> > trying to produce robust off-the-shelf software.  I just hope 
> > that any future version of filepro will separate application and 
> > and useage of a developer protection scheme from data access 
> > protection scheme (and make it obvious when expressed in the 
> > runtime).
> > 
> Bruce,
> 
> I disagree that the Creation Password is for Development only.  
> Remember that 
> filePro gives the user the ability to do some "development" at 
> time of run, for 
> example a "browse lookup", a regular browse layout when in IUA 
> and the variable 
> filename mentioned above that gave the user the ability to make 
> some kind of 
> generic logic.
> 
> What about all the options on the filePro Directory?  (delete 
> formats and files)
> 
> I never use creation passwords for the reasons indicated, but I 
> understand the 
> use and reasons.
> 
> Nancy

As I said above, I understand how the creation password evolved 
historically and that it operates consistently with the powers 
in filepro that it is associated with that you have mentioned.

But since the advent of variable filename capability, to me it is 
just downright silly to limit its capablity because of the 
creation password enforcement. I don't use them either - who 
would ever want an end-user getting prompted for something 
called a creation password?  Makes no sense.  And as Brian 
and others, when this was brought up before pointed out, 
there are still ways around the current enforcement anyway.

My main point as I said above is that there should be a clear 
distinction between a mechanism designed to protect user code 
and a mechanism designed to protect data and I think it is 
silly that filepro has version 5.6 and still has crippled 
the capability of a developer producing protected off-the-
shelf software for the lack of that distinction.  

I think it's a horrible idea to ask the end-user for 
any kind of password that is not related to data-protected 
authorization agreed to and designated in some way by the 
client (not the developer) and to ask it in the form "Enter 
Creation Password" is all the worse.  In a small operation 
where the developer - in-house perhaps, is working with 
the client closely and knows the exact data access level 
needs, then, yes what we have historically is fine.  But 
keeping it that way limits this dual creation protection/
data access protection in filepro apps to only be appropriate 
in that setting.

Now don't get me started on how we are at version 5.6 with 
a gajillion indexes and no way to express the index letter 
in a lookup as a variable:):).

Bruce

Bruce Easton
STN, Inc.