limiting browse based on login?

[scooter6 at gmail.com]

  Actually, I was just about to post and address this.

  I "think" I pretty much have the solution in place...but it does in fact
take
  several minutes to display their data because there are 1/2 million
records
  in the file that the browse lookup is pointing to...

  I'm still working on this, but headed in the right direction I believe

  Scott

On Wed, Sep 2, 2009 at 2:17 PM, Bruce Easton <bruce at stn.com> wrote:

> Mark wrote Wednesday, September 02, 2009 12:59 PM
> >
> > On Wed, Sep 02, 2009 at 12:34:43PM -0400, after drawing runes
> > in goat's blood, Bruce Easton cast forth these immortal,
> > mystical words:
> > >
> > > Mark - how is a qualified file not 'protected' verses an
> > unqualified file?
> >
> > All someone needs to do is:
> >
> > [be somewhere they can drop to a shell]
> > [drop to shell]
> > PFQUAL=qualifier;export PFQUAL
> > [run clerk or report]
> >
> > You can skip the environment variable if you remember the
> > flag for clerk/report.  I -think- it's -M but would have to
> > look it up.
> >
> > It's not like qualified files are encrypted.  They're named
> > differently.
> > This isn't rocket science.
> >
> > mark->
> > --
>
> Well if you can drop to a shell, you can drop to a shell and any
> solution - using qualified files or not is a potential problem.
>
> I like Tom Aldridge's solution as a complement to what I and others
> were suggesting because of the simplicity:
>
> -It doesn't involve using additional indexes for your internal
> primary file.
>
> -It keeps the separate clients usage of the files really separate.
>
> -It doesn't require much magic code for the user interface part to
> work and allows one to enter and use standard clerk features in a
> standard way.
>
> The only drawback I can see for this as a character-based solution is
> the up-front time the user must wait before they can access their
> up-to-date data.  (And I'm guessing this has not been a problem for him.)
>
> I haven't used this technique, but it seems like something that was
> probably a good solution before BBOCD (when @menu and @entsel came into
> being:
> the Big Bang of Overly-Complicated Design).
>
> Bruce
>
> Bruce Easton
> STN, Inc.
>
>
>
>
> _______________________________________________
>  Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20090902/efa4b1de/attachment.html