multiple search filter

[iara84]

The records of a data grid through a textbox and a button I search by name, identify, address and telephone by means using several filters but when searching I get the error operator/operand type mismatch. this is the code:

IF !EMPTY(THISFORM.Text1.Value)

SET FILTER TO
SET FILTER TO(clientes2.nombre) = ALLTRIM(thisform.text1.Value) OR (clientes2.identifica) = VAL(ALLTRIM(thisform.text1.Value)) OR (clientes2.direccion) = ALLTRIM(thisform.text1.Value) OR (clientes2.telefono) = VAL(ALLTRIM(thisform.text1.Value))
IF FOUND()
THISFORM.Refresh
ELSE
MESSAGEBOX("El valor especificado no existe")
ENDIF
ELSE
MESSAGEBOX("Porfavor introduzca un valor")
ENDIF

 

[Chris Miller]

Well, the data types of the cllientes2 fields have to match what you compare them to. You can use the same text1 value as is as string and as number by using VAL(), but is telefono actually a numeric field? Usually, telephone numbers are longer numbers and stored in character fields. If only to support area codes starting with 0. You cant store numbers with a leading 0 digit in integer nor unmeric or float.

In short, look at our table structure and make the comparisons work on the same data types.

Chriss

 

[Mike Lewis]

This looks very similar to the question you posted in thread184-1819225. In fact, your code (above) is almost the same as the code I suggested in that thread, except that, for some reason you are setting a filter rather than doing a LOCATE.

You had several replies to your earlier thread. It would have been helpful if you had indicated if any of those replies were useful to you. Or, at least, if you had come back to the thread to acknowledge the replies.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Another minor issue: I see you SET FILTER TO first, and in your earlier post you SET ORDER TO first. Neither FILTER nor ORDER are accumulative, it is sufficient to set whatever FILTER or ORDER you want to set straight away without first resetting it to no filter or no order. It doesn't break things to do so, but you gain nothing from it. So SET ORDER TO only becomes important if you want to see data in the physical DBF order and SET FILTER TO only becomes important if you want to see all data unfiltered.

And while I am at it, there is another error here, since you switched from Mikes recommended LOCATE to SET FILTER, you don't get FOUND() set, if you set a filter. You can do a pure LOCATE without any further clause after a SET FILTER TO which will put you to EOF(), if no record fulfills the filter or a record in line with the filter condition. This means EOF() is set and herefore also FOUND(). In general FOUND() can always be called and is the negation of EOF(). But SET FILTER alone can keep you at a recno which does not fulfill the filter and thus dos not put you at EOF(), while there still won't be a record found by a LOCATE, so you can get a false positive.

I also told in your earlier thread, that you better use LOCATE after SET FILTER to position on the first record fulfilling the filter condition(s). That's not automatic just by SET FILTER. It only most often happens, as you also have some list controls that then refresh and only show those records and position on one record without the explicit LOCATE.

And for sake of completeness, of course, you don't use SET FILTER TO followed by a LOCATE FOR <condition>. Neither the same and surely not another condition, LOCATE without any further clause is to be used and compares to LOCATE FOR .T. It works since thr FILTER is set that's taken into account, which means LOCATE puts you on the first filtered record.

Chriss