A foundset filter is what it says: A foundset filter. And foundsets might not live for the entire period of a Client session.
Secondly, you could have related foundsets based on the table where you want to apply filtering.
And you could have multiple forms on the table that require filtering and if you have the useSeparateFoundSet property checked on one of those forms, you got multiple foundsets, which you would all have to filter manually.
For you purpose, the Tablefilter is the best way to go.
Thanks for clarifying, Paul. Does this mean that addTableFilterParam also works on related foundsets? I thought I read on some other posts (http://forum.servoy.com/viewtopic.php?t=586) that this wasn’t the case, but it might’ve been fixed/improved since then…
TableFilters work on table level, so any foundset you base on that table will be filtered, whether related or not.
Note: You have to set the filter in your login/onSolutionStart method, before you have “touched” the table, which means as much as: If servoy has allready based a (related) foundset on the table on which you will try to apply the filter, the filter will not be applied.
So the TableFilter binds an additional where clause “table-filter” to the SQL statement from the time of the function call and for the duration of the client session? ie - if it is set immediately after Login it can be trusted in a SAAS environment?
I am assuming if this is so that one would still need to be careful while invoking plugins/beans (e.g. - embedded call to JasperReports)? Yes/no? Or, do Servoy plugins/beans honor this filter as well?
The tablefilter is indeed the way to go in SaaS solutions where the chosen SaaS implementation is one where the data of all customers is stored in the same database and tables, separated only by an “ownerid” column.
The tablefilter adds the additional where-clause to all SQL statements generated by Servoy. So, if you use your own SQl statements in your solution to get data, you need to take care of adding the additional where-clause yourself.
Same goes for Jasper Reports: You put the queries into the report, not Servoy (and the reports execute Server side, so not aware of what has been set in the Client).
Hi Paul
I have created modified a copy of the servoy crm application into a production ready saas application.
I added a “customerid” field to the udm tables, which i then use in the tablefilter. This field is filled with a unique customer code(eg 1000, 1001, etc) that is associated with the logged on user.
The problem i am experiencing is that when i click the delete button on the orders form, frm_order, the delete does not happen. In the debugger, the methos, controller.delete() does not perform the action.
The delete does however work on the crm contacts page, where exactly the same code is performed.
I tested the delete action on the servoy crm app (the original) and this works fine, but on my modified version it does not work on the orders form only.
Youe help would be greatly appreciated.
Thanks
Marcus
pbakker:
The tablefilter is indeed the way to go in SaaS solutions where the chosen SaaS implementation is one where the data of all customers is stored in the same database and tables, separated only by an “ownerid” column.
The tablefilter adds the additional where-clause to all SQL statements generated by Servoy. So, if you use your own SQl statements in your solution to get data, you need to take care of adding the additional where-clause yourself.
Same goes for Jasper Reports: You put the queries into the report, not Servoy (and the reports execute Server side, so not aware of what has been set in the Client).
This could be caused by relationships not allowing deletes.
Sounds as though you have added a relationship from logged in user to the Orders and the relationships properties may not be set to allow the delete to take place ?
Take a look at this thread which sounds like a similar issue: