Recent

Author Topic: IBX Filtering  (Read 223 times)

emilt

  • New member
  • *
  • Posts: 9
IBX Filtering
« on: June 29, 2020, 03:32:23 pm »
IBX for Lazarus  allows the use of the TDataset.Filter property for server side filtering - the value of the property gets added to the SelectSQL's WHERE clause.

This, however, interferes with client-side filtering. The server filter is applied regardless of of any OnFilterRecord handler that may be set. The handler then gets the records already filtered, and there is no way to pass a separate Filter information to do additional filtering client-side.

The TDataset.Filter help says
Quote
In general, the filter property accepts a SQL-like syntax usually encountered in the WHERE clause of an SQL SELECT statement.

However nothing prevents me (in TSQLQuery) to set the Filter value to any text that I can then use in the OnFilterRecord event to do my custom filtering (like apply different complex filtering rules based on this value).

In my view, the fact that I've defined an OnFilterRecord event means that I want to do client-filtering and the value of the Filter property is for use by the event handle and not by the database. This is easily solved with a one-line patch, but I don't know if enough people will agree with me so that it gets into the official source.

rvk

  • Hero Member
  • *****
  • Posts: 4157
Re: IBX Filtering
« Reply #1 on: June 29, 2020, 04:27:19 pm »
IBX for Lazarus  allows the use of the TDataset.Filter property for server side filtering - the value of the property gets added to the SelectSQL's WHERE clause.
The TSQLQuery.Filter does NOT add anything to the WHERE clause.

You have TSQLQuery.ServerFilter to add the filter to the SQL and use server-filtering
https://www.freepascal.org/docs-html/fcl/sqldb/tsqlquery.serverfilter.html

And you have TSQLQuery.Filter which does in-memory filtering on client side.
https://www.freepascal.org/docs-html/fcl/db/tdataset.filter.html

I hope IBX for Lazarus follows those same rules.

Edit: Ieks... Yes... TIBQuery (and not TDataset) applies the .Filter directly to the SQL statement.
So it doesn't follow the TDataset documentation (so you shouldn't look at that for TIBQuery.Filter)

In my view, the fact that I've defined an OnFilterRecord event means that I want to do client-filtering and the value of the Filter property is for use by the event handle and not by the database. This is easily solved with a one-line patch, but I don't know if enough people will agree with me so that it gets into the official source.
And what if you want to use both?
« Last Edit: June 29, 2020, 04:32:53 pm by rvk »

tonyw

  • Full Member
  • ***
  • Posts: 167
    • MWA Software
Re: IBX Filtering
« Reply #2 on: June 30, 2020, 10:21:53 am »
I can see the logic behind having separate properties for a "Where clause" filter for server side filtering and a property to hold directions for client side filtering (to be interpreted by the OnFilterRecord handler). My only concern is that changing this now might break someone else's code.

If I don't hear any strong objections then I will consider this as a change for the next release.

emilt

  • New member
  • *
  • Posts: 9
Re: IBX Filtering
« Reply #3 on: June 30, 2020, 12:23:07 pm »
+1 for the separate properties (the same as in TSQLQuery).

Keeping the current behavior when there is no OnFilterRecord  handler should minimize the compatibility problems.

And one thing more - applying a client side filter should not cause refreshing the dataset from the server.

 

TinyPortal © 2005-2018