enter creation password when lookup with qualifiers?

[Bruce Easton]

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

Bruce Easton
STN, Inc.