in a server/client environment, is there a 'faster' alternative to 'set filter to'
e.g.
on a 18900 rec size .dbf (39 fields), when i code for generating a report:
set filt to field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
go top
do whil !eof()
....
....
....
skip
end
-it slows down the process when 'skipping' records (or even at dbedit)

timec...@gmail.com schrieb am Mittwoch, 25. Januar 2023 um 10:27:44 UTC+1:
> in a server/client environment, is there a 'faster' alternative to 'set filter to'
> e.g.
> on a 18900 rec size .dbf (39 fields), when i code for generating a report:
> set filt to field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
> go top
> do whil !eof()
> ...
> ...
> ...
> skip
> end
> -it slows down the process when 'skipping' records (or even at dbedit)

copy to xxx.dbf for field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
And then no need for filter anymore.

Il 25/01/2023 10:38, Claude Roettgers ha scritto:

>> in a server/client environment, is there a 'faster' alternative to 'set filter to'
>> e.g.
>> on a 18900 rec size .dbf (39 fields), when i code for generating a report:
>> set filt to field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
>> go top
>> do whil !eof()
>> ...
>> ...
>> ...
>> skip
>> end
>> -it slows down the process when 'skipping' records (or even at dbedit)
>
> copy to xxx.dbf for field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
> And then no need for filter anymore.

Or build a temporary index with FOR clause on the fly.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

On Wednesday, January 25, 2023 at 3:08:28 PM UTC+5:30, Claude Roettgers wrote:
> timec...@gmail.com schrieb am Mittwoch, 25. Januar 2023 um 10:27:44 UTC+1:
> > in a server/client environment, is there a 'faster' alternative to 'set filter to'
> > e.g.
> > on a 18900 rec size .dbf (39 fields), when i code for generating a report:
> > set filt to field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
> > go top
> > do whil !eof()
> > ...
> > ...
> > ...
> > skip
> > end
> > -it slows down the process when 'skipping' records (or even at dbedit)
> copy to xxx.dbf for field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
> And then no need for filter anymore.
but, i have multiple index files on that .dbf, and i also change indexord in the loop...
wouldn't i then have to create multiple index files also on 'xxx.dbf'

On Wednesday, January 25, 2023 at 3:25:42 PM UTC+5:30, Enrico Maria Giordano wrote:
> Il 25/01/2023 10:38, Claude Roettgers ha scritto:
>
> >> in a server/client environment, is there a 'faster' alternative to 'set filter to'
> >> e.g.
> >> on a 18900 rec size .dbf (39 fields), when i code for generating a report:
> >> set filt to field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
> >> go top
> >> do whil !eof()
> >> ...
> >> ...
> >> ...
> >> skip
> >> end
> >> -it slows down the process when 'skipping' records (or even at dbedit)
> >
> > copy to xxx.dbf for field1=&abc .and. field7='C'.and.!dele().and.field8<invdate
> > And then no need for filter anymore.
> Or build a temporary index with FOR clause on the fly.
>
> --
> Enrico Maria Giordano
>
> http://www.emagsoftware.it
> http://www.emagsoftware.it/emgmusic
> http://www.emagsoftware.it/spectrum
> http://www.emagsoftware.it/tbosg
emg:
i have multiple index files on that dbf
-also, in dbedit, 'all' the 'non-filtered' records will also be listed/displayed...

Dear timec...

On Wednesday, January 25, 2023 at 3:35:29 AM UTC-7, timec...@gmail.com wrote:
....
> > > -it slows down the process when 'skipping' records
> > > (or even at dbedit)
> > copy to xxx.dbf for field1=&abc .and. field7='C'.and.
> > !dele().and.field8<invdate
> > And then no need for filter anymore.
....
> but, i have multiple index files on that .dbf, and i also
> change indexord in the loop... wouldn't i then have to
> create multiple index files also on 'xxx.dbf'

Use DBFCDX, and you have only a single index file, but multiple orderbags in that file. Yes, you'd still need to create each index, just refer to them by their alias.

If you have the "correct" index in place when you make the copy, then it will be in that order when you make it.

Another option is to create a separate "pointer file" that has records for matches into your main file, with fields associated with index position in each of your orderbags. Then build indexes on each of those. Smaller on disk, and that is about it.

You've complained (rightly) about the speed. We're trying to give you 'easy' fixes here. Only you can present them to the user in a fashion that allows them to feel this is faster. If you need to change indexes on main, create a new xxx.dbf to go with it.

El jueves, 26 de enero de 2023 a las 16:23:22 UTC+1, dlzc escribió:
> Dear timec...
>
> On Wednesday, January 25, 2023 at 3:35:29 AM UTC-7, timec...@gmail.com wrote:
> ...
> > > > -it slows down the process when 'skipping' records
> > > > (or even at dbedit)
> > > copy to xxx.dbf for field1=&abc .and. field7='C'.and.
> > > !dele().and.field8<invdate
> > > And then no need for filter anymore.
> ...
> > but, i have multiple index files on that .dbf, and i also
> > change indexord in the loop... wouldn't i then have to
> > create multiple index files also on 'xxx.dbf'
> Use DBFCDX, and you have only a single index file, but multiple orderbags in that file. Yes, you'd still need to create each index, just refer to them by their alias.
>
> If you have the "correct" index in place when you make the copy, then it will be in that order when you make it.
>
> Another option is to create a separate "pointer file" that has records for matches into your main file, with fields associated with index position in each of your orderbags. Then build indexes on each of those. Smaller on disk, and that is about it.
>
> You've complained (rightly) about the speed. We're trying to give you 'easy' fixes here. Only you can present them to the user in a fashion that allows them to feel this is faster. If you need to change indexes on main, create a new xxx.dbf to go with it.

Array recnos with filter in running on Array RDD

On Thursday, January 26, 2023 at 8:53:22 PM UTC+5:30, dlzc wrote:
thanks dlzc.
back to old dog...new tricks...
-it never ends.

btw: does chanting 'abracadabra' work.

> Dear timec...
>
> On Wednesday, January 25, 2023 at 3:35:29 AM UTC-7, timec...@gmail.com wrote:
> ...
> > > > -it slows down the process when 'skipping' records
> > > > (or even at dbedit)
> > > copy to xxx.dbf for field1=&abc .and. field7='C'.and.
> > > !dele().and.field8<invdate
> > > And then no need for filter anymore.
> ...
> > but, i have multiple index files on that .dbf, and i also
> > change indexord in the loop... wouldn't i then have to
> > create multiple index files also on 'xxx.dbf'
> Use DBFCDX, and you have only a single index file, but multiple orderbags in that file. Yes, you'd still need to create each index, just refer to them by their alias.
>
> If you have the "correct" index in place when you make the copy, then it will be in that order when you make it.
>
> Another option is to create a separate "pointer file" that has records for matches into your main file, with fields associated with index position in each of your orderbags. Then build indexes on each of those. Smaller on disk, and that is about it.
>
> You've complained (rightly) about the speed. We're trying to give you 'easy' fixes here. Only you can present them to the user in a fashion that allows them to feel this is faster. If you need to change indexes on main, create a new xxx.dbf to go with it.

Il 27/01/2023 06:08, timepro timesheet ha scritto:
> On Thursday, January 26, 2023 at 8:53:22 PM UTC+5:30, dlzc wrote:
> thanks dlzc.
> back to old dog...new tricks...
> -it never ends.
>
> btw: does chanting 'abracadabra' work.
>
BTW: keep in mind: traversating a dbf *with an index active* can be 10
times slower than with no indexes.

use dbf1
set index to ix1
go top
do while .not. eof()
skip
enddo

set index to
go top
do while .not. eof()
skip
enddo
=> the latter is MUCH faster (obviously).

Dan

On Thursday, January 26, 2023 at 10:08:57 PM UTC-7, timec...@gmail.com wrote:
> On Thursday, January 26, 2023 at 8:53:22 PM UTC+5:30, dlzc wrote:
> thanks dlzc.
> back to old dog...new tricks...
> -it never ends.
>
> btw: does chanting 'abracadabra' work.

If you speak the language, yes it does. That advice was English, but I expected you wanted to UNDERSTAND, not have someone write the code for you.

I'll stop responding to your posts.

David A. Smith

On Friday, January 27, 2023 at 8:41:50 PM UTC+5:30, dlzc wrote:
> On Thursday, January 26, 2023 at 10:08:57 PM UTC-7, timec...@gmail.com wrote:
> > On Thursday, January 26, 2023 at 8:53:22 PM UTC+5:30, dlzc wrote:
> > thanks dlzc.
> > back to old dog...new tricks...
> > -it never ends.
> >
> > btw: does chanting 'abracadabra' work.
> If you speak the language, yes it does. That advice was English, but I expected you wanted to UNDERSTAND, not have someone write the code for you.
>
> I'll stop responding to your posts.
>
> David A. Smith
whoa...whoa...
david, you overthink...
i bet, sans you all others believed (rightly) it was in jest...(abracadabra).
'i'll stop responding...' whatever man, but thanks for all your earlier inputs/responses. some really enlightened me.

furthermore, 'have someone write the code for me'. yeah, so what?. nothing remiss if i can get it done 'professionally' from an expert in this forum.