limiting browse based on login?

[scooter6 at gmail.com]

  Can someone point me in the direction of using qualifiers?
  I'm a little vague on how I would set that up.

  Currently, we have over 4000 clients - but only one that currently wants
to
  be able to VIEW their records - they will NOT be permitted to change a
single
  thing.....so, my plan using @menu and "drop" was to add @entsel processing
  with just "V" to view and once they view the record, they will also be
able to
  lookup to another file to VIEW notes we have on their records...but that's
it

  Until I find a bigger, permanent solution I will probably copy their
records each
  night to a "dummy" file and just build a view screen...that's easiest at
this point
  But I will continue to find a smoother way to do this as there are other
clients
  that will be forthcoming I'm told that will want this same functionality.

  Each "client number" can only have a maximum of 9999 records.
  i.e.  1234-0001 thru 1234-9999 -- once they have more records than that,
they
  are assigned another client number, etc.  Not an ideal scenario but this
is how
  it was built a long time ago...now we're getting more and more business
and
  several clients have exceeded 9999 records so we've had to add a second
and
  sometimes third client number - but that's another story in itself and
something
  that will require a major overhaul.

  Thanks for everyone's suggestions - I'm sure I'll/we'll find a way to make
this work

  For now, I'm still plugging away

  Scott



On Thu, Sep 3, 2009 at 9:19 AM, Tom Aldridge <toma at aldridgeinc.com> wrote:

> scooter6 at gmail.com wrote:
>
> >   I only have 1 client at this time that I'm building this for, but it
> will
> > be used more
> >   and more as I have heard we have several clients that have requested
> this
> >   functionality......
> >
> >   But, for this project, just 1 client and they will have about 600
> records
> > in
> >   the "browse lookup" file out of approx 550,000 so it does take a bit to
> > load
> >   just their records based on the 'drop' processing I'm using.....
>
> Hi. Are you the original poster on this? Anyway... not to just beat the
> drum over again on the qualifier thing, but now that I know you
> presently have one client who wants this and more on the way, I think
> maintaining the records at all times in the qualified files (vs the
> original suggestion to copy to the qualifier on the fly) would be nice
> and fast and clean. Browse processing is great for a many things
> including dropping records, but as you know,  not so when it comes to
> dropping lots and lots of records.... because it's reading every record
> and making a drop decision vs using an index.
>
> Depending on what you anticipate for the number of future clients vs any
> sort of filePro limitations to qualifiers, you could have each client
> work out of THEIR qualifier, and if you need to combine the various
> client records back into the main file, then do so as they create,
> update or delete their qualified records.
>
> What do you think of that?
>
> Tom Aldridge
>  _______________________________________________
> 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/20090903/e3574337/attachment.html