>Thanks for all the feedback guys.
>
>Hilmar, I'm not going to use the filter string in an SQL statement. I just need to filter the table.
>
>Tore, if I use a cursor, the updates wouldn't be written to the table in the database but to the cursor no?
>
>If I use INLIST(Department+Section+Unit,cDepSecUnit1,cDepSecUnit2,...) will it be better than using "$" ?
>
>Remember that my problem is that I may have more than one department, and for each department I may have a number of sections and then for each section I may have a number of units. The thing is that I can't say which records I may need. For example, I might need the following records:
>
>Dept A Sect 1 Unit a
>Dept A Sect 1 Unit b
>Dept B Sect 1 Unit a
>Dept C Sect 5 Unit g
>
>etc...
>
>That's why I was building up the string called "cDepSecUnit" with all the combinations and then using Department+Section+Unit $ cDepSecUnit.

$ is not a good solution.

INLIST have a bound limit ( max 25 items ), and it have i parsing overhead.

You can use a array,

aDepSecUnit[1]=[Dept A]+[Sect 1]+[Unit a]
aDepSecUnit[2]=[Dept A]+[Sect 1]+[Unit b]
...
SET FILTER TO !EMPTY(ASCAN(aDepSecUnit,Department+Section+Unit))

Of course,the better solution depends on the density of the filter condition,
if the density is low then an index on the table can improve the performances,
otherwise a simple scan can do the task.

Moreover, it depends on how many condition items (c1 and c2 and c3) are in OR,
if they are 50 or more then can to be useful to insert them in a indexed cursor,
and uses a SEEK( condition in this cursor like filter condition in the master table.

* cursor is useless, i want a index
CREATE CURSOR searchIndex (DepSecUnit C(N))
INSERT INTO searchIndex VALUES ([Dept A]+[Sect 1]+[Unit a])
INSERT INTO searchIndex VALUES ([Dept A]+[Sect 1]+[Unit b])
...
INDEX ON DepSecUnit TAG search
SET FILTER TO SEEK(Department+Section+Unit,'searchIndex') IN MasterTable

Fabio