TSQLQuery: ServerFilter causes Access Violation

[Milsa]

I have database application for work organization.

I set filter to (this show Lazarus during debugging):

Code: Pascal  [Select][+][-]

1. Filter = ANSISTRING($0C0E5F44)^: 'tor.partner_id = 10 AND done = 0'

It is ok, filter works.

But I add to filter new condition:

Code: Pascal  [Select][+][-]

1. Filter = ANSISTRING($0C07C23C)^: 'tor.partner_id = 10 AND tor.product_id = 114 AND done = 0'

It doesn't matter in which order I add the conditions, it always crashes if there are 3.

Order is set to:

Code: Pascal  [Select][+][-]

1. SELECT
2.   tor.*,
3.   tpr.name AS partner_name,
4.   tp.name AS product_name,
5.   SUM(tpw.hours) AS tpw_sum_hours
6. FROM [order] tor
7. INNER JOIN [partner] tpr ON tpr.id = tor.partner_id AND tpr.hide = 0
8. INNER JOIN [product] tp ON tp.id = tor.product_id AND tp.hide = 0
9. LEFT JOIN [product_work] tpw ON tpw.product_id = tp.id AND tpw.hide = 0
10. WHERE tor.hide = 0 AND tor.done = 0 AND tor.burden = 1
11. GROUP BY tor.id
12. ORDER BY serial;

Today I try newest version of Lazarus (3.4). The problem persists.

[Milsa]

Application crashes in line 2441.

[Milsa]

This is structure of my tables:

Code: Pascal  [Select][+][-]

1. CREATE TABLE [order] (
2.     id            INTEGER   PRIMARY KEY AUTOINCREMENT
3.                             NOT NULL,
4.     serial        TEXT (20) NOT NULL
5.                             UNIQUE,
6.     partner_id    INTEGER   NOT NULL
7.                             REFERENCES partner (id),
8.     product_id    INTEGER   NOT NULL
9.                             REFERENCES product (id),
10.     description   TEXT,
11.     priority      INTEGER   NOT NULL,
12.     date_finished DATE,
13.     color         INTEGER   DEFAULT (0)
14.                             NOT NULL,
15.     done          INTEGER   DEFAULT (0)
16.                             NOT NULL,
17.     overtime      INTEGER   DEFAULT (0)
18.                             NOT NULL,
19.     noinsert      INTEGER   NOT NULL
20.                             DEFAULT (0),
21.     burden        INTEGER   DEFAULT (0)
22.                             NOT NULL,
23.     hide          INTEGER   DEFAULT (0)
24.                             NOT NULL
25. );
26.  

Code: Pascal  [Select][+][-]

1. CREATE TABLE partner (
2.     id   INTEGER PRIMARY KEY AUTOINCREMENT
3.                  NOT NULL,
4.     name TEXT    NOT NULL
5.                  UNIQUE,
6.     hide INTEGER NOT NULL
7.                  DEFAULT (0)
8. );
9.  

Code: Pascal  [Select][+][-]

1. CREATE TABLE product (
2.     id   INTEGER PRIMARY KEY AUTOINCREMENT
3.                  NOT NULL,
4.     name TEXT    NOT NULL
5.                  UNIQUE,
6.     hide INTEGER NOT NULL
7.                  DEFAULT (0)
8. );
9.  

[Milsa]

The problem started appearing around Lazarus 2. I didn't notice this problem until then. Maybe it's a bug in the Lazarus code. But I can't confirm this for sure. I would have to try all the older versions of Lazarus one by one

[af0815]

Have you tuned on all debugging capabilities of Lazarus ?

Access violation like this are often dangling pointers. You can only go though the code there step by step and look in the watches to find out if the used variables and their content (and pointers) are the same you want to see.

[Zvoni]

Is ParseSQL set to False?
https://www.freepascal.org/docs-html/fcl/sqldb/tsqlquery.serverfilter.html

EDIT: Don't set ServerFiltered to False in Line 2438?
From my Link above

If the dataset is active and ServerFiltered is set to true, then changing this property will re-fetch the data from the server.

[CharlyTango]

Firstly, I would check whether the SQL statement you are sending is syntactically and result-wise correct.
I would test this with an external programme.
As I don't know which operating system you are using, I can't recommend one.

And the I'd follow af0815's advice to step-debug your code to see where exactly a problem exists.

It would also be interesting to see how exactly you create the SQL statement in the code. Even better would be a small test project against an SQL database so that you can see the problem in real life