I reported yesterday (Sorting by a related column and corruption of foundset - Classic Servoy - Servoy Community) a bug appearing to be linked to how servoy handles relations involving a column with null values.
Apparently, this bug is linked to the same subject; how servoy is interpreting nulls. Here are two copies of the stacktrace to demonstrate it:
stacktrace:
Find executed, time: 0 thread: AWT-EventQueue-0, sql:
select distinct(rContacts.f0001) from rContacts,rCommunications where rCommunications.f0016 like ? and rContacts.f0001 = rCommunications.f0013 and ? = rCommunications.f0008 order by rContacts.f0001used sql select rCommunications.f0001 from rCommunications where rCommunications.f0013 = ? and rCommunications.f0018 = ? and rCommunications.f0015 = ? and rCommunications.f0008 is null order by rCommunications.f0001 questiondata.lenght 4
Both stacktrace concerns the same conditions: the column f0008 from table rCommunications must be equal to a global initialized to contain null, read: ‘f0008 is null’.
The first stacktrace reflects how servoy is interpreting the condition in a find, obviously if you replace the question mark by null, the query would not be executed because sybase sql requires ‘is’ as operator to compare with null.
The second stacktrace shows that the case of a null is correctly interpreted when servoy is dealing with a relation.
Please can you check that the null exception is correctly handled when servoy is generating queries for find, sort and so on… ?