[HM] New post at Harbour Magazine

[José Luis Sánchez]

Nueva entrada en Harbour Magazine, sobre como usar opciones de filtrado en Harbour.
https://medium.com/harbour-magazine/pon ... 6dbb92f275

New post at Harbour Magazine, about how th use filtering options with Harbour.
https://medium.com/harbour-magazine/put ... 240aea74e0

Regards,
José Luis

[Otto]

Hello Luis,
thank you for your post and work.
Maybe you can compare filters to temporary index too.
Best regards,
Otto

[José Luis Sánchez]

Hello Otto,
I think that filters are powerfull than temporary indexes. With filters you can change the index order and the filter remains, and this behavour is very hard to obtain with temporary indexes.

Regards,
José Luis

[Otto]

Hello Luis,
For me filters where always dangerous because you never new if you have set somewhere a filter and then you reused the workspace and got wrong results.
You write in your article that you have a warning build in – which is very good and important.
As creating a temporary dbf-file which the “filtered” result is very fast these days (SSD disks) I use this technique much.
Best regards,
Otto

[James Bott]

Otto,

For me filters where always dangerous because you never new if you have set somewhere a filter and then you reused the workspace and got wrong results

.

I'm not sure if you meant reusing a database object or reusing a workspace. With database objects you don't ever have to deal with workspaces. You can always open another copy of the same database object--then you don't have those problems.

If you prefer to use the same object, then you should always save and restore it's state (recno(), index, filter, etc.) in the particular routine (function or method) then you won't have those problems either. Save it at the start of the routine and restore it at the end.

However, I don't use filters either--they are just too slow and require extra programming (like the above).

James

[nageswaragunupudi]

I think that filters are powerfull than temporary indexes. With filters you can change the index order and the filter remains, and this behavour is very hard to obtain with temporary indexes.

I too hold the same opinion. But we should know how the RDD optimizes performance with filters.

they are just too slow

This is a very very old story.
Yes, they were slow till Foxpro came up with Rushmore technology long time back. Later comix and six implemented same technology. Present DBFCDX too implements the same. They can be quite fast but we need to understand how the RDD optimizes filters.

[Enrico Maria Giordano]

they are just too slow

This is a very very old story.
Yes, they were slow till Foxpro came up with Rushmore technology long time back. Later comix and six implemented same technology. Present DBFCDX too implements the same. They can be quite fast but we need to understand how the RDD optimizes filters.

Please can you show a test demonstrating what you stated? I'm sincerely curious to see a SET FILTER that is not unacceptably slow.

EMG