Search the FirstSpirit Knowledge Base
I have been searching in the community, but it does not seem to have an answer for my problem, unless I overlooked it.
We are using FirstSpirit 4.2.489 in which we want to write a query with a not like. From the community I understand the "NOT LIKE" functionality is not supported in FirstSpirit and there is no alternative to it. This means in our case we have the following problem:
We have a list with departements in our organization which include for example BZ, BZK, BZK/a, BZK/b. BZ/a, BZ/b. Now in order to create a drop down list with only the departements BZ together with it's sub departements (e.g. BZ, BZ/a, BZ/b in the example above) we would like to exectue a query "WHERE LIKE 'BZ' AND NOT LIKE 'BZK'".
I would like to know if there is a workaround with which we can implement to get the result we want?
If there is no known workaround, I would like to know if there is a way to extend the query component in order to write such functionality ourselves, and then I would also like to know where I could find the right documentation to do so.
And last, I know there is a feature request for this "NOT LIKE" implementation already since 2011. I would like to know if this feature is going to be implemented (or maybe already has been implemented) in FirstSpirit 5?
I hope someone can help me out.
If I think of a third department BZX, your "query" would have to be changed every time such a department is added...
What about a query like
WHERE x = "BZ" OR x LIKE "BZ/" (note the slash)?
Of course translated into the FirstSpirit Query syntax.
Hello Michael,
Indeed you are correct. If a new departement is added there is a chance some or more of the query's has to be rewritten.
The above query example could work for a BZ and only new extensions behind the company, but would not work for a new departement XBZ.
Perhaps you introduce categories for your department and use a query to select all departments of a specific category? Then you can assign new departments to a category instead of changing queries..
Hi Peter,
I was thinking already in a similar direction. This would mean however I with have to make a change in the data (which actually means a change of the functional representation of the data). For me this is not a big problem, but could be a problem for the business.
It is a solution though, so I am going to think about it and try to make a suggestion towards the business.
Thanks.