Not at first, none. When it comes to SQL, taking into account the versions 2.0 from Firebird, the code you showed is no better than the code below:
SELECT CK.IDCHEK,
CK.DESCHE,
null AS ENTEGU
FROM TC_CHECKL CK
ORDER BY CK.IDCHEK
I searched for possible bugs in Firebird, but I couldn’t find any related to the query.
So, besides possible error of the programmer who made SQL, I believe that two things could be the causes:
1) Due to compatibility with the components used in Delphi. Perhaps using the SQL of my answer, the components detect the ENTEGU field as if it were of a different type (float or string) to the current SQL.
2) Select was more complicated, using other fields, but it was optimized. To avoid possible errors, the programmer kept the (SELECT null FROM RDB$DATABASE)
.
Embarrassment is correct, there is no reason to use it. If we try to think of reasons for this, the guy who made this sql might use this selection as a substitution point. Example: At runtime, by means of a Stringreplace, it might exchange null for a given field and rdb$database for a table. This in this context would create the possibility to define at runtime where the value of the field would come from. The very use of this process within an 'onDraw' reveals a certain degree of inexperience of the guy, because this event is not appropriate to open queryes not by far
– RaphaelZ
I am being denied without explanation here. But I firmly believe that the answer is correct. If you wish you can show me where I am wrong.
– EMBarbosa