Using addTableFilterParam()

This method behaves a bit strange. When I run a filter on application launch it’s applied throughout the whole application successfully (except when I call a query to fill a dynamic value list).
Then at runtime I apply another filter to choose, for example, employees with names starting with ‘w’. The filter is applied successfully.
And here is where the weird things happen. I open my search screen and search for employees with names starting with ‘g’.

  1. First of all, the ‘g’ employees are loaded in the search screen which is what I want but what I would not expect with my ‘w’ filter applied. The search is made by query (databaseManager.getDatasetByQuery()) and loaded in a form that uses a separate foundset.

The further the more weird things.
2. After I search for ‘g’ employees I select one of them for viewing and append this record to the foundset of my first screen that has that ‘w’ filter applied (I append it by getting the foundset’s query, getting the dataset of the PKs with the help of this query and adding a row with the selected ‘g’ employee PK to it, then loading the resulting dataset in the form). And I still can see the ‘w’ employees together with the selected ‘g’ employee/ Why did the ‘w’ filter not exclude the ‘g’ employee from the list?

This behavior is exactly (well, with minor imperfections) what I want to implement but I don’t understand why the filter works so strange.

(If I go to search again after selecting one ‘g’ employee and appending it to the ‘w’ list, and select another employee, say, ‘r’ employee, then the ‘g’ employee disappears from the list but the ‘r’ employee is still there. I would like to keep both of them and be able to add more).

Any ideas on what is going on behind the screen are most welcome.

  1. And a bit of a conceptual question: is the method addTableFilterParam() supposed to be used on start up only or is it just another method to be played with at any place in the application. We are dealing with filters that the users are able to create, store and remove whenever they like. Is this method the best way to work with filters for us?

Cheers,
Maria

Maria,

Which version of Servoy are you using?

Rob

Hi Rob,

I’m using Version 4.1.2.i6 if this helps. Do you have any ideas?

Cheers,
Maria

Maria,

The reason the filter did not remove the keys that did not match was because the records were already cached in the Servoy engine.
Servoy already had the data and filters are only applied when the database is queried.

This is an issue and will be fixed in next Servoy release.
This covers 1) and 2) I think

ad 3) Since Servoy 3.5 addTableFilterParam() can be used at any time in the application and apply to all non-custom sql queries.
When given a name, you can also remove them again with removeTableFilterParam().

Rob

Thanks Rob.

Does it mean that, in the next release, if the filters are applied to a foundset it is totally impossible to get filtered records until the filter is removed? There are situations like, for instance, we want to have a filtered foundset of records in a table view for a user but we still want the enable the user to search ALL records in a search window. For that, would it be a good practice to apply a filter to the foundset, then, when the user opens the search window, to remove the filter to show all records, and then to apply the filter again when the search window is closed (the window is modal)?

Cheers,
Maria

Hello everyone,

Please, see the topic viewtopic.php?f=22&t=12470#p63111 and tell me if we should use addTableFilterParam or something else like servoy find/search for that scenario.

Thank you.

Maria,

Table filter params are designed to filter out data that should never be accessible by the user, all queries generated by Servoy (so not custom-queries) will have the condition included.
Although it can be applied any time and removed, best practice is to set them at client login and never remove them.

Rob

Hi Maria,

Maybe using foundsetfilters would be of help to you. A foundset filter applies to a specific foundset and can be removed by calling loadAllRecords() on that specific foundset object.

Paul

Paul, we have been trying for 3 days to remove a foundset filter and we also tried loadAllRecords which didn’t do the job. You might email Lenore if you know some trick we don’t.

Gary

Can you explain the advantages and disadvantages of using a foundsetfilter vs a tablefilter? The tablefilter has getTableFilterParam and removeTableFilterParams that the foundset doesn’t.

I stand corrected on what I said before: a loadAllRecords() on a foundset with FoundSetFilters applied will not remove the filters.

Currently, FoundSetFilters, once set, are permanent for that specific FoundSet object.

What you can do is create a new FoundSet object using “var FoundSetObject = databaseManager.getFoundSet(…);” and load that FoundSet into your form using “controller.loadRecords(FoundSetObject);”

Paul

The difference between a tableFilter and a FoundSetFilter is that a FoundSetFilter applies only to 1 specific FoundSet.

So if you have 10 different FoundSets on the Customers table and you apply a FoundSetFilter to one of the FoundSets, only that specific FoundSet instance is affected.

If you would apply the same filter but using the tableFilter functionality, then the Filter would be applied to all FoundSet instances.

Paul

Hi Paul,

pbakker:
What you can do is create a new FoundSet object using “var FoundSetObject = databaseManager.getFoundSet(…);” and load that FoundSet into your form using “controller.loadRecords(FoundSetObject);”

Wouldn’t that create a ‘seperate’ foundset? I.e. if you had a list and detail form using the same foundset and you set the list form foundset to this new foundset object then the detail form would not be linked to this list form anymore?
Or am I mistaken?

Right, you’d have to set teh new FoundSet object into both the list and detail view.

Paul

That sure does sound like a lot of trouble. This just does not seem to be a viable solution for us. We have this situation throughout our application and also have this complicated with record locking, databroadcasting and record validation. Why can’t we just have the commands removeFoundSetFilterParam and getFoundSetFilterParams so we can handle this on our own? BTW, we put in a case for this as a feature request. I hope the Servoy developers see the need as we do.

Hi Lenore,

I fully support that featurerequest. I am looking for that kind of functionality in our application-framework. The only way now is to do it with Servoy-find and search…

I’m glad to hear the need is there for others. The find feature doesn’t work for us because we always have autosave off.

The find() command doesn’t work if you have edits that are not committed.
A find does a query on the db, so if records are not saved they are not in the database.

Leonore

I fully support your feature request. We would love to have that functionality with the foundset filters described before. We work with auto save off as well.

Good luck for us!

Cheers,

Lenore:
I’m glad to hear the need is there for others. The find feature doesn’t work for us because we always have autosave off.

We support the feature request, too.
With autosave set to off, the only way for us to filter a foundset is to do a query and load records.
Enabling the user to retrieve and remove the foundset filter parameters seems like a very logical way of doing things.

Cheers,
Maria

With autosave set to off, the only way for us to filter a foundset is to do a query and load records.

Just note that if you have autosave off and there are edited records in the foundset on which you try to apply a foundsetfilter, this will also fail. You need to save the records first.

Paul