| Subject | RE: [IBO] Problem with parameters in query |
|---|---|
| Author | Jason Wharton |
| Post date | 2018-10-26T20:37:43Z |
Tomasz,
Excellent idea!
This is something I will take into consideration as I firm up my
architecture for the next major version of IBO, which actually won't be
called IBO anymore. I am in the process of working on a major rewrite that
will open things up to tap into other database backend products. I'm
calling it Enterprise Data Objects. EDO.
The concept you mention here suggests that I have some parameters that the
programmer can define at design-time and then get flagged as immutable.
This means the statement will have its input parameters effective cast to be
what the programmer defined, as you said. I believe this would be a
worthwhile aspect for EDO, but perhaps a bit too late in the game for IBO.
Regarding EDO:
I'm getting close to having an early alpha, so if anyone is interested in
following this development, send me a private email and I'll arrange some
kind of an NDA and then we can work more closely. I'm hoping to find a
couple of collaboraters on this project or perhaps even an employment
arrangement with synergistic benefits.
Kind regards,
Jason Wharton
www.ibobjects.com
-----Original Message-----
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
Sent: Sunday, September 17, 2017 2:28 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Problem with parameters in query
On 17.09.2017 at 19:09, 'Jason Wharton' supportlist@...
[IBObjects] wrote:
to be of. I mean, when one writes aQuery.ParamByName('aParam').AsString :=
s, what one expects is 'aParam'
to be assigned the provided string value (if one believed it to be an int,
one would use AsInteger). If aParam is used multiple times in a query, just
set it with the same string every time (instead of trying to check if it
really is a string in all occurences). If a param is assigned a value of an
incompatible type (with respect to the context it's being used in), the
query execution will fail and that's it. That seems to be straightforward
and intuitive (like writing a query in isql
- if you compare values of incompatible types, the query fails), unless
libfbclient for some reason forbids it.
My hack does just that: don't check the param type, just believe that when I
say it's a float, a float it is.
have a good one
Tomasz
__--==============================--__
__--== Tomasz Tyrakowski ==--__
__--== SOL-SYSTEM ==--__
__--== http://www.sol-system.pl ==--__
__--==============================--__
------------------------------------
------------------------------------
___________________________________________________________________________
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
Excellent idea!
This is something I will take into consideration as I firm up my
architecture for the next major version of IBO, which actually won't be
called IBO anymore. I am in the process of working on a major rewrite that
will open things up to tap into other database backend products. I'm
calling it Enterprise Data Objects. EDO.
The concept you mention here suggests that I have some parameters that the
programmer can define at design-time and then get flagged as immutable.
This means the statement will have its input parameters effective cast to be
what the programmer defined, as you said. I believe this would be a
worthwhile aspect for EDO, but perhaps a bit too late in the game for IBO.
Regarding EDO:
I'm getting close to having an early alpha, so if anyone is interested in
following this development, send me a private email and I'll arrange some
kind of an NDA and then we can work more closely. I'm hoping to find a
couple of collaboraters on this project or perhaps even an employment
arrangement with synergistic benefits.
Kind regards,
Jason Wharton
www.ibobjects.com
-----Original Message-----
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
Sent: Sunday, September 17, 2017 2:28 PM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Problem with parameters in query
On 17.09.2017 at 19:09, 'Jason Wharton' supportlist@...
[IBObjects] wrote:
> [...]Maybe just leave it to the programmer to decide what type the parameter is
> 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.
to be of. I mean, when one writes aQuery.ParamByName('aParam').AsString :=
s, what one expects is 'aParam'
to be assigned the provided string value (if one believed it to be an int,
one would use AsInteger). If aParam is used multiple times in a query, just
set it with the same string every time (instead of trying to check if it
really is a string in all occurences). If a param is assigned a value of an
incompatible type (with respect to the context it's being used in), the
query execution will fail and that's it. That seems to be straightforward
and intuitive (like writing a query in isql
- if you compare values of incompatible types, the query fails), unless
libfbclient for some reason forbids it.
My hack does just that: don't check the param type, just believe that when I
say it's a float, a float it is.
have a good one
Tomasz
>written this way).
> -----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
> 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
>
>
>
>
__--==============================--__
__--== Tomasz Tyrakowski ==--__
__--== SOL-SYSTEM ==--__
__--== http://www.sol-system.pl ==--__
__--==============================--__
------------------------------------
------------------------------------
___________________________________________________________________________
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