Hiya list,

Having my curiosity piqued by a recent discussion about an inability to
bind a Boolean in a WHERE clause with certain versions of JDBC, I
discovered that my InformixDB Python module has the same problem. To
correct this, I have added a DESCRIBE INPUT step to the query
preparation step. Now I have discovered that older ESQL/C versions don't
support the DESCRIBE INPUT statement, so I have to add conditional
compilation to skip this step if ESQL/C doesn't understand it.

My problem is that I don't know which version of ESQL/C introduced this
statement. I only know that ESQL/C 9.21 doesn't support it and IBM
ESQL/C 2.90, which would be something like 9.6+ in the old continuum of
versions, does. That leaves a large gray area that contains the dividing
line I'm looking for.

The online documentation doesn't seem to contain a hint about a minimum
ESQL/C version. It only says that that IDS 9.4+ is required. If I assume
that version numbers are logical, I could extrapolate that I'd need
ESQL/C 9.4+, but that's based on a questionable assumption.

Does anybody with knowledge of Informix history have a definitive
answer?

Thanks,

--
Carsten Haese
http://informixdb.sourceforge.net

On Oct 14, 9:21 am, Carsten Haese <cars...@uniqsys.com> wrote:
> Hiya list,

Hello Carsten,

>
> Having my curiosity piqued by a recent discussion about an inability to
> bind a Boolean in a WHERE clause with certain versions of JDBC, I
> discovered that my InformixDB Python module has the same problem.


Do you mind explaining under which conditions this is happening?

If I understand correctly, InformixDB is having problems with queries
like

"select * from employees where active = ?"

where 'active' is boolean.

I want to know how to reproduce it in order to know if Ruby/Informix
is affected.

The previous query worked as expected with Informix 11, CSDK 2.90 and
Ruby/Informix. But maybe I'm missing something.

--
Gerardo Santana

On Sun, 2007-10-14 at 16:10 +0000, Gerardo Santana wrote:
> On Oct 14, 9:21 am, Carsten Haese <cars...@uniqsys.com> wrote:
> > Hiya list,
>
> Hello Carsten,
>
> >
> > Having my curiosity piqued by a recent discussion about an inability to
> > bind a Boolean in a WHERE clause with certain versions of JDBC, I
> > discovered that my InformixDB Python module has the same problem.
>
>
> Do you mind explaining under which conditions this is happening?
>
> If I understand correctly, InformixDB is having problems with queries
> like
>
> "select * from employees where active = ?"
>
> where 'active' is boolean.

That is correct, until the next version

> I want to know how to reproduce it in order to know if Ruby/Informix
> is affected.
>
> The previous query worked as expected with Informix 11, CSDK 2.90 and
> Ruby/Informix. But maybe I'm missing something.

I've taken a quick look at your code, and it is indeed not affected by
this bug, but it has another bit of surprising behavior. You simply bind
True as the string 't' and False as the string 'f'. That works well
enough if you only ever bind True and False to Boolean columns. However,
users of older engines might want to bind a boolean value to a numeric
column (int/smallint), in which case your binding will fail.

My code takes a different approach. It interprets True as 1 and False as
0, so that they can be bound to numeric columns, and when the
destination is a boolean, the input parameter is bound as an actual
SQLBOOL. That requires knowing the type of the destination, which was
easy enough to obtain with DESCRIBE for INSERT and UPDATE statements,
and those have worked for a while. However, for SELECT statements, my
approach requires a DESCRIBE INPUT step, which wasn't done until now.

Another advantage of knowing the destination type is that it allows
Python's duck-typing semantics: you can bind any object, not just
True/False to a boolean column. If an arbitrary object is bound to a
boolean column, it's automatically cast into a bool first.

Whether you need to do any of this depends on what your users expect.
What my module does is "Pythonic". I don't know what "Rubyic" behavior
requires

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net

On Oct 14, 11:29 am, Carsten Haese <cars...@uniqsys.com> wrote:
> On Sun, 2007-10-14 at 16:10 +0000, Gerardo Santana wrote:
> > I want to know how to reproduce it in order to know if Ruby/Informix
> > is affected.
>
> > The previous query worked as expected with Informix 11, CSDK 2.90 and
> > Ruby/Informix. But maybe I'm missing something.
>
> I've taken a quick look at your code, and it is indeed not affected by
> this bug, but it has another bit of surprising behavior. You simply bind
> True as the string 't' and False as the string 'f'. That works well
> enough if you only ever bind True and False to Boolean columns. However,
> users of older engines might want to bind a boolean value to a numeric
> column (int/smallint), in which case your binding will fail.


Ok, fair enough.
I'll keep that behavior, since in Ruby land there's no numeric
interpretation for true or false.


>
> My code takes a different approach. It interprets True as 1 and False as
> 0, so that they can be bound to numeric columns, and when the
> destination is a boolean, the input parameter is bound as an actual
> SQLBOOL. That requires knowing the type of the destination, which was
> easy enough to obtain with DESCRIBE for INSERT and UPDATE statements,
> and those have worked for a while. However, for SELECT statements, my
> approach requires a DESCRIBE INPUT step, which wasn't done until now.


I see. Informix itself doesn't provide a cast from integer to boolean.
I think I will keep that too.

>
> Another advantage of knowing the destination type is that it allows
> Python's duck-typing semantics: you can bind any object, not just
> True/False to a boolean column. If an arbitrary object is bound to a
> boolean column, it's automatically cast into a bool first.
>
> Whether you need to do any of this depends on what your users expect.
> What my module does is "Pythonic". I don't know what "Rubyic" behavior
> requires

Certainly

Thank you for the explanation!

--
Gerardo

On 14 Oct, 16:21, Carsten Haese <cars...@uniqsys.com> wrote:
> Hiya list,
>
> Having my curiosity piqued by a recent discussion about an inability to
> bind a Boolean in a WHERE clause with certain versions of JDBC, I
> discovered that my InformixDB Python module has the same problem. To
> correct this, I have added a DESCRIBE INPUT step to the query
> preparation step. Now I have discovered that older ESQL/C versions don't
> support the DESCRIBE INPUT statement, so I have to add conditional
> compilation to skip this step if ESQL/C doesn't understand it.
>
> My problem is that I don't know which version of ESQL/C introduced this
> statement. I only know that ESQL/C 9.21 doesn't support it and IBM
> ESQL/C 2.90, which would be something like 9.6+ in the old continuum of
> versions, does. That leaves a large gray area that contains the dividing
> line I'm looking for.
>
> The online documentation doesn't seem to contain a hint about a minimum
> ESQL/C version. It only says that that IDS 9.4+ is required. If I assume
> that version numbers are logical, I could extrapolate that I'd need
> ESQL/C 9.4+, but that's based on a questionable assumption.
>
> Does anybody with knowledge of Informix history have a definitive
> answer?
>
> Thanks,
>
> --
> Carsten Haesehttp://informixdb.sourceforge.net

Pick the current version now and tell users to use that.

The Client SDK is small, users can just install the version required
into a seperate folder.

Since the Client SDK is a free download most people don't even both to
pay for support for it.

Although there are have been bugs in the Client SDK I have never hit
any of them!

On Sun, 2007-10-14 at 13:15 -0700, david@smooth1.co.uk wrote:
> Pick the current version now and tell users to use that.

Thanks, but I'll call that Plan B. I prefer not to force gratuitous
upgrades on my users.

--
Carsten Haese
http://informixdb.sourceforge.net

On Oct 14, 2:34 pm, Carsten Haese <cars...@uniqsys.com> wrote:
> On Sun, 2007-10-14 at 13:15 -0700, da...@smooth1.co.uk wrote:
> > Pick the current version now and tell users to use that.
>
> Thanks, but I'll call that Plan B. I prefer not to force gratuitous
> upgrades on my users.


It surprises me to know there are that many users of old Informix
versions. DBD::Informix supports very old Informix versions too.

I'm curious, is there a report about how many Informix users are for
each major release?

On Oct 14, 8:21 am, Carsten Haese <cars...@uniqsys.com> wrote:
> [...] I have added a DESCRIBE INPUT step to the query
> preparation step. Now I have discovered that older ESQL/C versions don't
> support the DESCRIBE INPUT statement, so I have to add conditional
> compilation to skip this step if ESQL/C doesn't understand it.
>
> My problem is that I don't know which version of ESQL/C introduced this
> statement. I only know that ESQL/C 9.21 doesn't support it and IBM
> ESQL/C 2.90, which would be something like 9.6+ in the old continuum of
> versions, does. That leaves a large gray area that contains the dividing
> line I'm looking for. [...]

You need the ESQL/C that was released with IDS 9.40 - for, as you
observe, IDS 9.30 did not support DESCRIBE INPUT but IDS 9.40 does.

The I-Connect distributed with IDS 9.40 is 2.81; therefore, the
corresponding CSDK is 2.81. That contains ESQL/C 9.53 - the last
version before the numbers reset to 2.90 in synchrony with the CSDK
version number.

DBD::Informix does not yet use DESCRIBE INPUT.

On Mon, 2007-10-15 at 17:29 +0000, Jonathan Leffler wrote:
> [...] You need the ESQL/C that was released with IDS 9.40 - [...] ESQL/C 9.53

I knew I could count on you to give me a definitive answer. Thanks!

--
Carsten Haese
http://informixdb.sourceforge.net

On 17 oct, 08:45, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
> It would be interesting to see a Ruby or Python replacement to 4GL.

What about Ruby on Rails (for new projects)?

> I've become a big fan of Python. I'd be a bigger fan if I didn't have to
> rely on cx_Oracle and oracle's stupid concepts of user and temp tables.
> (Those who know oracle and IDS know exactly what I mean. ;-)

Try Ruby ;-)

--
Gerardo Santana