Tomasz,

Thank you for your comments and you are accurate in what you have stated.

I'm a bit uncertain how Firebird reacts when I cast things in the manner
that I do in order to get duplicate named parameters of different types to
work as the programmer expects.

I really do wish Firebird would have accepted named parameters so that this
wouldn't be such a headache, but I am doing my best to only make assumptions
that I know I can make.

Cheers,
Jason Wharton
www.ibobjects.com


-----Original Message-----
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
Sent: Thursday, August 31, 2017 5:26 AM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Problem with parameters in query

On 31.08.2017 at 09:43, Svein Erling Tysvær setysvar@... [IBObjects]
wrote:

> [...]
> 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.

I have struggled with "parameters with duplicate names" as well, 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 ==--__
__--==============================--__


------------------------------------
Posted by: Tomasz Tyrakowski <t.tyrakowski@...>
------------------------------------

___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
http://tracker.ibobjects.com - your portal to submit and monitor bug reports
http://community.ibobjects.com - your portal to purchase and upgrade
------------------------------------

Yahoo Groups Links