English > Support

Problem with advanced search

<< < (2/3) > >>

buah:
Maybe I'm doing something wrong now, but I noticed two additional issues now regarding Advanced Search:

1. ID is not any more comparable like:">, <, >=, <=" etc? Like it was now defined as a text field? It now contains conditions:"containing, not containing, like, not like" and not aboves.

2. This one is rather general, but further explained through an example. I have a custom text field "To Download Data" that could be "No" or "NULL". When I set filter "To Download Data" containing "No", I got like 50 results, and that's ok. But I want to get a list of other 5450 entries in order to download data. When I set filter "To Download Data" not containing "No", I got zero results? And, if i set it "To Download Data" IS NULL I got desirable 5450 results. Why is that, and is it how it supposed to be?

All in all, first issue is rather important, IMHO!

Cheers

nostra:

--- Quote ---1. ID is not any more comparable like:">, <, >=, <=" etc? Like it was now defined as a text field? It now contains conditions:"containing, not containing, like, not like" and not aboves.
--- End quote ---

ID is now a field that can contained letters + numbers combination that is why you do not get >, <, >=, <= operators, but I agree it is no good, so I will try to think smth out for users who do not add letters to IDs


--- Quote ---2. This one is rather general, but further explained through an example. I have a custom text field "To Download Data" that could be "No" or "NULL". When I set filter "To Download Data" containing "No", I got like 50 results, and that's ok. But I want to get a list of other 5450 entries in order to download data. When I set filter "To Download Data" not containing "No", I got zero results? And, if i set it "To Download Data" IS NULL I got desirable 5450 results. Why is that, and is it how it supposed to be?
--- End quote ---

NULL Fields are always treated a bit differently by the database engine. containing, not containing operators only check fields with  smth in them and ignore NULL values.

buah:

--- Quote from: nostra on February 09, 2010, 12:36:47 pm ---NULL Fields are always treated a bit differently by the database engine. containing, not containing operators only check fields with  smth in them and ignore NULL values.
--- End quote ---

Thank you for clearing that to me! Now everything is perfectly logical.


--- Quote from: nostra on February 09, 2010, 12:36:47 pm ---ID is now a field that can contained letters + numbers combination that is why you do not get >, <, >=, <= operators, but I agree it is no good, so I will try to think smth out for users who do not add letters to IDs.
--- End quote ---

If I'm allowed to practice brainstorming, I would say that ID could be contained of two fields, displayed as one: text field and number field. Additional checkbox (checked in, or not) in Preferences named for instance "Use letters for ID, too" would cause adequate advanced search operators to be triggered?

If am not that clear, I'd like to elaborate further.

Cheers

nostra:

--- Quote ---If I'm allowed to practice brainstorming, I would say that ID could be contained of two fields, displayed as one: text field and number field.
--- End quote ---

It is exactly the case now.


--- Quote ---Additional checkbox (checked in, or not) in Preferences named for instance "Use letters for ID, too" would cause adequate advanced search operators to be triggered?
--- End quote ---

It seems like you are right

rick.ca:

--- Quote ---NULL Fields are always treated a bit differently by the database engine.
--- End quote ---

See Expressions Involving NULL in this reference. I've found the tip of thinking of NULL as UNKNOWN particularly helpful.

Navigation

[0] Message Index

[#] Next page

[*] Previous page