limiting browse based on login?

[scooter6 at gmail.com]

      Okay, well I decided to go in another direction on this due to time
constraints.
      What I did is create a new file that mirrors the 'main' file NRdebtor
      I copied over JUST the records for the client that wants access so
just their
      records are in this file - they will ONLY be allowed to browse their
data,
      nothing else.

      So I created a simple screen that will show just the pertinent info,
etc.

      Now, what I want to do is copy over just their records in a nightly
cron job

      So, to do this, what is the command to delete all the records (except
1 blank)
      from this new "mirror" file that has only this clients data in it?
      I know how to get the records copied from the main file, but am unsure
how to
      delete these records before copying over a 'fresh' version - hope that
makes
      sense.  I suspect it will be ddir or something to delete the records
before I
      re-copy them, is that correct?

      Thanks for all the help - but using every form of "drop" and "drop
all" still just
      takes too long since filePro apparently has to search each individual
record,
      even if using an index based on unique account number, since there are
over
      1/2 million records it's just not a good solution at this point - this
other
       'solution' involves probably a little more heavy lifting than might
be necessary
      but it does the trick.

      I am currently writing the @menu portion so the client will only be
able to hit
      'V' to view and 'X' to exit, etc.

     Thanks again

       Scott



On Thu, Sep 3, 2009 at 7:29 PM, Ken Cole <ken.m.cole at gmail.com> wrote:

> Tom,
>
>  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.
>>
>
> I have always found the "drop all before" and "drop all after" work
> extremely well and stops filePro from checking any more records which is why
> I wasn't sure why the original request wasn't done in a browse on the
> original data file using both these commands.  It makes this sort of
> functionality simple, quick and clean.
>
> Ken
>
> _______________________________________________
> 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/20090911/b82e1517/attachment-0001.html