Subject | Re: [IBO] Problem with parameters in query |
---|---|
Author | Tomasz Tyrakowski |
Post date | 2017-08-31T11:26:12Z |
On 31.08.2017 at 09:43, Svein Erling Tysvær setysvar@...
[IBObjects] wrote:
eventually some hacks to IBO source allowed me to get rid of them (at
the cost of risking uncompatible uses of a parameter to go unnoticed,
but that's the risk I had to take, being in a situation similar to
Helmut's - over a million lines of old Delphi code with thousands of
embedded SQL queries, some of them generated dynamically in code).
But getting back to the point, I consider code readability a top
priority (especially in large codebases). The first query clearly states
what the programmer had in mind writing it, while the second one proves
you're very fluent in caveats of Firebird's SQL, but it would take quite
a while for another programmer (especially a junior one) to deduce what
you really are trying to get from the DB (imagine how a more complicated
query joining several tables would look like when written this way).
So, IMHO we should all write clear and readable code and it's up to the
component layer to cope with the technical limitations of a DB client
library. And Jason is doing quite well in this matter, so I believe we
won't have to use many workarounds.
Sorry if I sound like criticizing - nothing of the sort (especially not
you SET - I'm a regular firebird-support reader and occasional poster,
so I do appreciate your knowledge), just wanted to emphasize that we
should write code that explains itself. The rest is in Jason's hands ;)
best regards
Tomasz
--
__--==============================--__
__--== Tomasz Tyrakowski ==--__
__--== SOL-SYSTEM ==--__
__--== http://www.sol-system.pl ==--__
__--==============================--__
[IBObjects] wrote:
> [...]I have struggled with "parameters with duplicate names" as well,
> SELECT <whatever>
> FROM MyTable
> WHERE Field1 = :MyParam
> OR Field2 = :MyParam
>
> and rather write things like:
>
> WITH TMP(MyTmpField) AS
> (SELECT CAST(:MyParam AS <whatever>) FROM RDB$DATABASE)
> SELECT <whatever>
> FROM MyTable M
> JOIN TMP T ON M.MyTmpField = T.Field1
> OR M.MyTmpField = T.Field2
>
> This change will not help you today (of course), but writing your SQL so
> that it really only has one direct reference to each parameter would avoid
> potential future pitfalls like the one you're experiencing today.
eventually some hacks to IBO source allowed me to get rid of them (at
the cost of risking uncompatible uses of a parameter to go unnoticed,
but that's the risk I had to take, being in a situation similar to
Helmut's - over a million lines of old Delphi code with thousands of
embedded SQL queries, some of them generated dynamically in code).
But getting back to the point, I consider code readability a top
priority (especially in large codebases). The first query clearly states
what the programmer had in mind writing it, while the second one proves
you're very fluent in caveats of Firebird's SQL, but it would take quite
a while for another programmer (especially a junior one) to deduce what
you really are trying to get from the DB (imagine how a more complicated
query joining several tables would look like when written this way).
So, IMHO we should all write clear and readable code and it's up to the
component layer to cope with the technical limitations of a DB client
library. And Jason is doing quite well in this matter, so I believe we
won't have to use many workarounds.
Sorry if I sound like criticizing - nothing of the sort (especially not
you SET - I'm a regular firebird-support reader and occasional poster,
so I do appreciate your knowledge), just wanted to emphasize that we
should write code that explains itself. The rest is in Jason's hands ;)
best regards
Tomasz
--
__--==============================--__
__--== Tomasz Tyrakowski ==--__
__--== SOL-SYSTEM ==--__
__--== http://www.sol-system.pl ==--__
__--==============================--__