DBD::Informix Update statements crashing engine

DBD::Informix Update statements crashing engine

Post by Corey D. Herbe » Fri, 02 May 2003 07:19:25



running on Red Hat Linux Advanced Server release 2.1AS/i686 Kernel
2.4.9-e.1, with Informix
IDS 9.40UC1, CSDK 2.5UC2 with DBD-Informix-2003.04, we're getting some
behavior that's
undesirable, to say the least.

we have a script, using prepared statements, AutoCommit=>0, it runs the same
UPDATE statement several times with no problems.  however, with a certain
set of bind-parameters, it returns an execute failed error, errno -25580,
and it crashes the informix instance.  here's the finderr 25580:

A system call has failed. For assistance, contact your system administrator

it appears that the query always fails & causes the crash on the same set of
parameters, however, besides differnet numeric values, these parameters are
very similar to parameters being used successfully (and by that i mean, both
the failure set and the successful sets have nulls & not-nulls in the same
columns).

we have been able to run the query with the parameters that causes the crash
in dbaccess without error or crash.  we completely dropped & rebuilt the
table that the query was against, to no avail.  we are able to run the
statement that fails as an insert (ie, same values) through dbi/dbd, and it
succeeds.

we have gotten this same behavior from another script doing an update on a
differnet table.

Corey Herbel

 
 
 

DBD::Informix Update statements crashing engine

Post by Jonathan Leffle » Fri, 02 May 2003 12:06:07



> running on Red Hat Linux Advanced Server release 2.1AS/i686 Kernel
> 2.4.9-e.1, with Informix IDS 9.40UC1, CSDK 2.5UC2 with
> DBD-Informix-2003.04, we're getting some behavior that's
> undesirable, to say the least.

> we have a script, using prepared statements, AutoCommit=>0, it runs the same
> UPDATE statement several times with no problems.  however, with a certain
> set of bind-parameters, it returns an execute failed error, errno -25580,
> and it crashes the informix instance.  here's the finderr 25580:

You should not be able to crash an Informix instance from a client
program -- so there's a bug.  However, you haven't given us much to go
on, like a simple reproduction, which makes life more difficult in
analysing what the trouble is.

> A system call has failed. For assistance, contact your system administrator


And what did they say when you called?

Quote:> it appears that the query always fails & causes the crash on the same set of
> parameters, however, besides differnet numeric values, these parameters are
> very similar to parameters being used successfully (and by that i mean, both
> the failure set and the successful sets have nulls & not-nulls in the same
> columns).

> we have been able to run the query with the parameters that causes the crash
> in dbaccess without error or crash.  we completely dropped & rebuilt the
> table that the query was against, to no avail.  we are able to run the
> statement that fails as an insert (ie, same values) through dbi/dbd, and it
> succeeds.

Actually, you have not run the same query in DB-Access; you said you
were using bound variables, and DB-Access does not allow you to use
bound variables.

Quote:> we have gotten this same behavior from another script doing an update on a
> differnet table.

OK.   Are you using shared memory connections or sockets?  Have you
tried using the other?  I'm going to need to see a simplified version
of your code that does successfully crash the server.  I will need
enough schema to reproduce the problem.  I would like to see your
ONCONFIG file and (the relevant entries from) your sqlhosts file.
This will tell me things like which data types are involved.  I may
end up asking you for some extra information - but let's get going
with this lot.  CSDK 2.50.UC2 is not all that recent, but it should be
OK.  Which version of DBI are you using?  1.35 is a reasonable guess,
but let's be sure.  And which version of Perl (perl -V)?  They aren't
likely to be very important, but we'll get all the details while I
have your attention.

--

#include <disclaimer.h>
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

 
 
 

DBD::Informix Update statements crashing engine

Post by Corey Herbe » Sat, 03 May 2003 06:13:43


Environment setting, sqlhosts, and onconfig are at the bottom of this email.

When I spoke with Informix, they said they can't do much since DBD isn't a supported
product.  They did say they'd help isolate why the system crashes, because as you stated a
client programs should not crash the server.  We are putting together a script along with
dbschema and SQLIDEBUG output for their use.  I'll send them directly to you under the
cover of a different email.

I'd imagine it's important to say the server crashes whether its using SHM or TCP.  It's
also important to note, when we rebuild the prepare statements for each update it does not
fail. Finally, another oddity is the system never seems to crash the first time an update
is run, it is on a subsequent update.  Although we can't confirm that statement.

Thanks,
Corey

> Corey D. Herbel wrote:

>> running on Red Hat Linux Advanced Server release 2.1AS/i686 Kernel
>> 2.4.9-e.1, with Informix IDS 9.40UC1, CSDK 2.5UC2 with
>> DBD-Informix-2003.04, we're getting some behavior that's undesirable,
>> to say the least.

>> we have a script, using prepared statements, AutoCommit=>0, it runs
>> the same
>> UPDATE statement several times with no problems.  however, with a certain
>> set of bind-parameters, it returns an execute failed error, errno -25580,
>> and it crashes the informix instance.  here's the finderr 25580:

> You should not be able to crash an Informix instance from a client
> program -- so there's a bug.  However, you haven't given us much to go
> on, like a simple reproduction, which makes life more difficult in
> analysing what the trouble is.

>> A system call has failed. For assistance, contact your system
>> administrator
>> or Technical Support at tsm...@us.ibm.com.

> And what did they say when you called?

>> it appears that the query always fails & causes the crash on the same
>> set of
>> parameters, however, besides differnet numeric values, these
>> parameters are
>> very similar to parameters being used successfully (and by that i
>> mean, both
>> the failure set and the successful sets have nulls & not-nulls in the
>> same
>> columns).

>> we have been able to run the query with the parameters that causes the
>> crash
>> in dbaccess without error or crash.  we completely dropped & rebuilt the
>> table that the query was against, to no avail.  we are able to run the
>> statement that fails as an insert (ie, same values) through dbi/dbd,
>> and it
>> succeeds.

> Actually, you have not run the same query in DB-Access; you said you
> were using bound variables, and DB-Access does not allow you to use
> bound variables.

>> we have gotten this same behavior from another script doing an update
>> on a
>> differnet table.

> OK.   Are you using shared memory connections or sockets?  Have you
> tried using the other?  I'm going to need to see a simplified version of
> your code that does successfully crash the server.  I will need enough
> schema to reproduce the problem.  I would like to see your ONCONFIG file
> and (the relevant entries from) your sqlhosts file. This will tell me
> things like which data types are involved.  I may end up asking you for
> some extra information - but let's get going with this lot.  CSDK
> 2.50.UC2 is not all that recent, but it should be OK.  Which version of
> DBI are you using?  1.35 is a reasonable guess, but let's be sure.  And
> which version of Perl (perl -V)?  They aren't likely to be very
> important, but we'll get all the details while I have your attention.

I've updated CSDK: IBM/Informix-Client SDK Version 2.81.UC1
Copyright (C) 1991-2003 IBM

perl -V: Summary of my perl5 (revision 5.0 version 6 subversion 1)
DBI: DBI-1.35
INFORMIXSERVER=prodb1a
INFORMIXDIR=/usr/informix

/etc/services
# Local services
prodtcp         1501/tcp                        # Main instance of Informix

sqlhost
prodb1a            onipcshm       prodb1a      bogus
prodb1atcp         onsoctcp       prodb1a      prodtcp
stats2tcp         onsoctcp       stats2      prodtcp
prod_live_tcp           onsoctcp       prod        prodtcp
stats1tcp         onsoctcp       stats1      prodtcp
develtcp          onsoctcp       devel       prodtcp
prod2tcp          onsoctcp       prod2       prodtcp

onconfig
#**************************************************************************
#
#                          INFORMIX SOFTWARE, INC.
#
#  Title:       onconfig.std
#  Description: Informix Dynamic Server 2000 Configuration Parameters
#
#**************************************************************************
ROOTNAME        rootdbs         # Root dbspace name
ROOTPATH        /usr/informix/chunks/rootdbs # Path for device containing root dbspace
ROOTOFFSET      0               # Offset of root dbspace into device (Kbytes)
ROOTSIZE        70000           # Size of root dbspace (Kbytes)
MIRROR          0               # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH                      # Path for device containing mirrored root
MIRROROFFSET    0               # Offset into mirrored device (Kbytes)
PHYSDBS         physdbs         # Location (dbspace) of physical log
PHYSFILE        25000           # Physical log file size (Kbytes)
LOGFILES        12              # Number of logical log files
LOGSIZE         10000           # Logical log size (Kbytes)
MSGPATH         /usr/informix/logs/online.log # System message log file path
CONSOLE         /dev/console    # System console message path
ALARMPROGRAM    /usr/informix/etc/log_full.sh # Alarm program path
TBLSPACE_STATS  1               # Maintain tblspace statistics
#TAPEDEV         /usr/informix/chunks/db_backups/db # Tape device path
TAPEDEV         172.16.1.9:/dev/tape1
#TAPEDEV         /dev/null
TAPEBLK         16              # Tape block size (Kbytes)
TAPESIZE        4000000         # Maximum amount of data to put on tape (Kbytes)
LTAPEDEV        /usr/informix/chunks/db_backups/log_tape # Log tape device path
LTAPEBLK        16              # Log tape block size (Kbytes)
LTAPESIZE       6144000         # Max amount of data to put on log tape (Kbytes)
STAGEBLOB                       # Informix Dynamic Server 2000 staging area
SERVERNUM       0               # Unique id corresponding to a OnLine instance
DBSERVERNAME    prodb1a            # Name of default database server
DBSERVERALIASES prodb1atcp         # List of alternate dbservernames
NETTYPE         ipcshm,1,50,CPU # Configure poll thread(s) for nettype
NETTYPE         soctcp,1,50,NET # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60              # Max time to wait of lock in distributed env.
RESIDENT        0               # Forced residency flag (Yes = 1, No = 0)
MULTIPROCESSOR  1               # 0 for single-processor, 1 for multi-processor
NUMCPUVPS       2               # Number of user (cpu) vps
SINGLE_CPU_VP   0               # If non-zero, limit number of cpu vps to one
NOAGE           0               # Process aging
AFF_SPROC       0               # Affinity start processor
AFF_NPROCS      0               # Affinity number of processors
LOCKS           50000          # Maximum number of locks
BUFFERS         85000          # Maximum number of shared buffers
NUMAIOVPS       28              # Number of IO vps
PHYSBUFF        60              # Physical log buffer size (Kbytes)
LOGBUFF         48              # Logical log buffer size (Kbytes)
LOGSMAX         13              # Maximum number of logical log files
CLEANERS        64               # Number of buffer cleaner processes
SHMBASE         0x10000000        #define SHMBASE 0x10000000L   # Shared memory base address
SHMVIRTSIZE     485000          # initial virtual shared memory segment size
SHMADD          16000           # Size of new shared memory segments (Kbytes)
SHMTOTAL        897000          # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL       300             # Check point interval (in sec)
LRUS            12              # Number of LRU queues
LRU_MAX_DIRTY   60              # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY   50              # LRU percent dirty end cleaning limit
LTXHWM          50              # Long transaction high water mark percentage
LTXEHWM         60              # Long transaction high water mark (exclusive)
TXTIMEOUT       0x12c             # Transaction timeout (in sec)
STACKSIZE       32              # Stack size (Kbytes)
STMT_CACHE      0               # Statement Cache is available for use (0=OFF, 1=ON with
ENV, 2=ON Always).
STMT_CACHE_SIZE 72              # Statement Cache Size available for use (default is 72k).
OFF_RECVRY_THREADS 10              # Default number of offline worker threads
ON_RECVRY_THREADS 1               # Default number of online worker threads
DRINTERVAL      -1              # DR max time between DR buffer flushes (in sec)
DRTIMEOUT       30              # DR network timeout (in sec)
DRLOSTFOUND     /usr/informix/etc/dr.lostfound # DR lost+found file path
CDR_EVALTHREADS 1,2             # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT  5               # DS lockwait timeout (seconds)
CDR_QUEUEMEM    4096            # Maximum amount of memory for any CDR queue (Kbytes)
CDR_LOGDELTA    30              # % of log space allowed in queue memory
CDR_NUMCONNECT  16              # Expected connections per server
CDR_NIFRETRY    300             # Connection retry (seconds)
CDR_NIFCOMPRESS 0               # Link level compression (-1 never, 0 none, 9 max)
BAR_ACT_LOG     /tmp/bar_act.log
BAR_MAX_BACKUP  0
BAR_RETRY       1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE off
BAR_PROGRESS_FREQ 0
ISM_DATA_POOL   ISMData
ISM_LOG_POOL    ISMLogs
RA_PAGES        64              # Number of pages to attempt to read ahead
RA_THRESHOLD    16              # Number of pages left before next group
DBSPACETEMP     tempdbs1,tempdbs2 # Default temp dbspaces
DUMPDIR         /tmp            # Preserve
...

read more »

 
 
 

DBD::Informix Update statements crashing engine

Post by Corey Herbe » Sat, 03 May 2003 06:13:43


Environment setting, sqlhosts, and onconfig are at the bottom of this email.

When I spoke with Informix, they said they can't do much since DBD isn't a supported
product.  They did say they'd help isolate why the system crashes, because as you stated a
client programs should not crash the server.  We are putting together a script along with
dbschema and SQLIDEBUG output for their use.  I'll send them directly to you under the
cover of a different email.

I'd imagine it's important to say the server crashes whether its using SHM or TCP.  It's
also important to note, when we rebuild the prepare statements for each update it does not
fail. Finally, another oddity is the system never seems to crash the first time an update
is run, it is on a subsequent update.  Although we can't confirm that statement.

Thanks,
Corey

> Corey D. Herbel wrote:

>> running on Red Hat Linux Advanced Server release 2.1AS/i686 Kernel
>> 2.4.9-e.1, with Informix IDS 9.40UC1, CSDK 2.5UC2 with
>> DBD-Informix-2003.04, we're getting some behavior that's undesirable,
>> to say the least.

>> we have a script, using prepared statements, AutoCommit=>0, it runs
>> the same
>> UPDATE statement several times with no problems.  however, with a certain
>> set of bind-parameters, it returns an execute failed error, errno -25580,
>> and it crashes the informix instance.  here's the finderr 25580:

> You should not be able to crash an Informix instance from a client
> program -- so there's a bug.  However, you haven't given us much to go
> on, like a simple reproduction, which makes life more difficult in
> analysing what the trouble is.

>> A system call has failed. For assistance, contact your system
>> administrator
>> or Technical Support at tsm...@us.ibm.com.

> And what did they say when you called?

>> it appears that the query always fails & causes the crash on the same
>> set of
>> parameters, however, besides differnet numeric values, these
>> parameters are
>> very similar to parameters being used successfully (and by that i
>> mean, both
>> the failure set and the successful sets have nulls & not-nulls in the
>> same
>> columns).

>> we have been able to run the query with the parameters that causes the
>> crash
>> in dbaccess without error or crash.  we completely dropped & rebuilt the
>> table that the query was against, to no avail.  we are able to run the
>> statement that fails as an insert (ie, same values) through dbi/dbd,
>> and it
>> succeeds.

> Actually, you have not run the same query in DB-Access; you said you
> were using bound variables, and DB-Access does not allow you to use
> bound variables.

>> we have gotten this same behavior from another script doing an update
>> on a
>> differnet table.

> OK.   Are you using shared memory connections or sockets?  Have you
> tried using the other?  I'm going to need to see a simplified version of
> your code that does successfully crash the server.  I will need enough
> schema to reproduce the problem.  I would like to see your ONCONFIG file
> and (the relevant entries from) your sqlhosts file. This will tell me
> things like which data types are involved.  I may end up asking you for
> some extra information - but let's get going with this lot.  CSDK
> 2.50.UC2 is not all that recent, but it should be OK.  Which version of
> DBI are you using?  1.35 is a reasonable guess, but let's be sure.  And
> which version of Perl (perl -V)?  They aren't likely to be very
> important, but we'll get all the details while I have your attention.

I've updated CSDK: IBM/Informix-Client SDK Version 2.81.UC1
Copyright (C) 1991-2003 IBM

perl -V: Summary of my perl5 (revision 5.0 version 6 subversion 1)
DBI: DBI-1.35
INFORMIXSERVER=prodb1a
INFORMIXDIR=/usr/informix

/etc/services
# Local services
prodtcp         1501/tcp                        # Main instance of Informix

sqlhost
prodb1a            onipcshm       prodb1a      bogus
prodb1atcp         onsoctcp       prodb1a      prodtcp
stats2tcp         onsoctcp       stats2      prodtcp
prod_live_tcp           onsoctcp       prod        prodtcp
stats1tcp         onsoctcp       stats1      prodtcp
develtcp          onsoctcp       devel       prodtcp
prod2tcp          onsoctcp       prod2       prodtcp

onconfig
#**************************************************************************
#
#                          INFORMIX SOFTWARE, INC.
#
#  Title:       onconfig.std
#  Description: Informix Dynamic Server 2000 Configuration Parameters
#
#**************************************************************************
ROOTNAME        rootdbs         # Root dbspace name
ROOTPATH        /usr/informix/chunks/rootdbs # Path for device containing root dbspace
ROOTOFFSET      0               # Offset of root dbspace into device (Kbytes)
ROOTSIZE        70000           # Size of root dbspace (Kbytes)
MIRROR          0               # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH                      # Path for device containing mirrored root
MIRROROFFSET    0               # Offset into mirrored device (Kbytes)
PHYSDBS         physdbs         # Location (dbspace) of physical log
PHYSFILE        25000           # Physical log file size (Kbytes)
LOGFILES        12              # Number of logical log files
LOGSIZE         10000           # Logical log size (Kbytes)
MSGPATH         /usr/informix/logs/online.log # System message log file path
CONSOLE         /dev/console    # System console message path
ALARMPROGRAM    /usr/informix/etc/log_full.sh # Alarm program path
TBLSPACE_STATS  1               # Maintain tblspace statistics
#TAPEDEV         /usr/informix/chunks/db_backups/db # Tape device path
TAPEDEV         172.16.1.9:/dev/tape1
#TAPEDEV         /dev/null
TAPEBLK         16              # Tape block size (Kbytes)
TAPESIZE        4000000         # Maximum amount of data to put on tape (Kbytes)
LTAPEDEV        /usr/informix/chunks/db_backups/log_tape # Log tape device path
LTAPEBLK        16              # Log tape block size (Kbytes)
LTAPESIZE       6144000         # Max amount of data to put on log tape (Kbytes)
STAGEBLOB                       # Informix Dynamic Server 2000 staging area
SERVERNUM       0               # Unique id corresponding to a OnLine instance
DBSERVERNAME    prodb1a            # Name of default database server
DBSERVERALIASES prodb1atcp         # List of alternate dbservernames
NETTYPE         ipcshm,1,50,CPU # Configure poll thread(s) for nettype
NETTYPE         soctcp,1,50,NET # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60              # Max time to wait of lock in distributed env.
RESIDENT        0               # Forced residency flag (Yes = 1, No = 0)
MULTIPROCESSOR  1               # 0 for single-processor, 1 for multi-processor
NUMCPUVPS       2               # Number of user (cpu) vps
SINGLE_CPU_VP   0               # If non-zero, limit number of cpu vps to one
NOAGE           0               # Process aging
AFF_SPROC       0               # Affinity start processor
AFF_NPROCS      0               # Affinity number of processors
LOCKS           50000          # Maximum number of locks
BUFFERS         85000          # Maximum number of shared buffers
NUMAIOVPS       28              # Number of IO vps
PHYSBUFF        60              # Physical log buffer size (Kbytes)
LOGBUFF         48              # Logical log buffer size (Kbytes)
LOGSMAX         13              # Maximum number of logical log files
CLEANERS        64               # Number of buffer cleaner processes
SHMBASE         0x10000000        #define SHMBASE 0x10000000L   # Shared memory base address
SHMVIRTSIZE     485000          # initial virtual shared memory segment size
SHMADD          16000           # Size of new shared memory segments (Kbytes)
SHMTOTAL        897000          # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL       300             # Check point interval (in sec)
LRUS            12              # Number of LRU queues
LRU_MAX_DIRTY   60              # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY   50              # LRU percent dirty end cleaning limit
LTXHWM          50              # Long transaction high water mark percentage
LTXEHWM         60              # Long transaction high water mark (exclusive)
TXTIMEOUT       0x12c             # Transaction timeout (in sec)
STACKSIZE       32              # Stack size (Kbytes)
STMT_CACHE      0               # Statement Cache is available for use (0=OFF, 1=ON with
ENV, 2=ON Always).
STMT_CACHE_SIZE 72              # Statement Cache Size available for use (default is 72k).
OFF_RECVRY_THREADS 10              # Default number of offline worker threads
ON_RECVRY_THREADS 1               # Default number of online worker threads
DRINTERVAL      -1              # DR max time between DR buffer flushes (in sec)
DRTIMEOUT       30              # DR network timeout (in sec)
DRLOSTFOUND     /usr/informix/etc/dr.lostfound # DR lost+found file path
CDR_EVALTHREADS 1,2             # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT  5               # DS lockwait timeout (seconds)
CDR_QUEUEMEM    4096            # Maximum amount of memory for any CDR queue (Kbytes)
CDR_LOGDELTA    30              # % of log space allowed in queue memory
CDR_NUMCONNECT  16              # Expected connections per server
CDR_NIFRETRY    300             # Connection retry (seconds)
CDR_NIFCOMPRESS 0               # Link level compression (-1 never, 0 none, 9 max)
BAR_ACT_LOG     /tmp/bar_act.log
BAR_MAX_BACKUP  0
BAR_RETRY       1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE off
BAR_PROGRESS_FREQ 0
ISM_DATA_POOL   ISMData
ISM_LOG_POOL    ISMLogs
RA_PAGES        64              # Number of pages to attempt to read ahead
RA_THRESHOLD    16              # Number of pages left before next group
DBSPACETEMP     tempdbs1,tempdbs2 # Default temp dbspaces
DUMPDIR         /tmp            # Preserve
...

read more »

 
 
 

DBD::Informix Update statements crashing engine

Post by rkusene » Sat, 03 May 2003 09:11:19



> When I spoke with Informix, they said they can't do much since DBD isn't a supported
> product.

Jonathan,

I hope now it is clear why the bank voted against Perl DBD.

ravi
=========================================================


Quote:> > As the bank decided on an in-house tool for ETL, I was recommending Perl
> > DBI/DBD for that. In my view that would have been the best choice for that.
> > However the bank voted against Perl because of questionable support from
> > Informix. Finally had to do it in 'C'.

> I am probably being a little over-sensitive here, but ...
> Why was the Informix support for Perl in question?  What about the
> support of Perl itself, or DBI?  Why was the support for DBD::Informix
> any different from the other parts of the Perl ensemble?

> I'm not really willing to put 6-10 people through the hoops necessary
> to get an official release of DBD::Informix when one person can do 95%
> of the work in the same amount of time (and fixing the 5% that a QA
> and release team might have caught doesn't take all that much extra
> time). I do not think it is cost effective, in other words.

This is how the conversation went:-

Bank Official: How much does Perl cost?

Myself: It is free. Perl is an open source language.

BO: Free???. Is it something supported by Informix.

Myself: No it is not an official product from Informix. AFAIK ,
it is supported by one employee of Informix. And if I am right,
Oracle supports Perl DBD/DBI (though I am not 100% sure).

BO: Hmm.. And if that employee quits Informix????

Right or wrong, big corporations do not operate like this. They
want someone to be accountable if something goes wrong.

Ravi

 
 
 

DBD::Informix Update statements crashing engine

Post by Jonathan Leffle » Sat, 03 May 2003 13:49:55




>>When I spoke with Informix, they said they can't do much since DBD isn't a supported
>>product.

> Jonathan,

> I hope now it is clear why the bank voted against Perl DBD.

Yes - it is clear that no-one knows how to pitch the problem correctly
at Tech Support.

"I have an ESQL/C application which is crashing the database".

Perl and DBI and DBD::Informix are purely and simply (well, maybe not
all that simply) an ESQL/C application.

The fact that it involves Perl or DBD::Informix is purely incidental;
it is an ESQL/C application which is crashing the database.  That is a
critical problem - or damn well should be.

Further, when we get down to reproducing the problem (Corey has sent
me the data which he thinks I'll need, based on what I told him I'd
need), the first thing I do will be to remove Perl and DBD::Informix
from the equation, leaving a nice simple reproduction in pure ESQL/C,
which will then be a bug in ESQL/C and/or IDS, and the problem is back
squarely where it belongs.

Of course, just as with any other bug report, it would be a whole heap
better if the customer did the refinement and reduction to a more or
less minimal test case -- it should not be something that Tech Support
(eg me) has to do -- but I'm used to people not being able to do that.

There is nothing that any application program should be able to do via
regular communication channels with the database server using ESQL/C
statements that should *ever* crash the database server.  Period!

It's the bank's loss.  It's also infuriating.  The problem would
actually occur even if IBM/Informix supported it.

Yes, I know - I've been there, seen it, etc.  I prototyped a system
using Perl - and then had to rewrite it in ESQL/C and C.  That was a
real pain, but at least I had the prototype to guide me.  And
extensions were always developed in Perl and then converted to C and
ESQL/C.  I left shortly after that.

> ravi
> =========================================================


>>>As the bank decided on an in-house tool for ETL, I was recommending Perl
>>>DBI/DBD for that. In my view that would have been the best choice for that.
>>>However the bank voted against Perl because of questionable support from
>>>Informix. Finally had to do it in 'C'.

>>I am probably being a little over-sensitive here, but ...

>>Why was the Informix support for Perl in question?  What about the
>>support of Perl itself, or DBI?  Why was the support for DBD::Informix
>>any different from the other parts of the Perl ensemble?

>>I'm not really willing to put 6-10 people through the hoops necessary
>>to get an official release of DBD::Informix when one person can do 95%
>>of the work in the same amount of time (and fixing the 5% that a QA
>>and release team might have caught doesn't take all that much extra
>>time). I do not think it is cost effective, in other words.

> This is how the conversation went:-

> Bank Official: How much does Perl cost?

> Myself: It is free. Perl is an open source language.

> BO: Free???. Is it something supported by Informix.

> Myself: No it is not an official product from Informix. AFAIK ,
> it is supported by one employee of Informix. And if I am right,
> Oracle supports Perl DBD/DBI (though I am not 100% sure).

> BO: Hmm.. And if that employee quits Informix????

> Right or wrong, big corporations do not operate like this. They
> want someone to be accountable if something goes wrong.

> Ravi

--
Jonathan Leffler                   #include <disclaimer.h>

Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
 
 
 

1. Telneting to Informix server port crashes the Engine!

Hello everyone!

Can anyone tell me why when I telnet to the informix service port (ifmx_srvc
2055/tcp) and type "auth" or any other set of chars and press enter this
process crashes the Informix engine???

Any input will be greatly appreciated!

Best regards,
Neo
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

2. importing dbase 5 files into sqlserver2000

3. Informix 7.10.UD1 Online Engine Crashed Big Time

4. Quicken style code lookup

5. Update -Statement crashes CDX/FoxPro-Indexes

6. Can You Navigate Userdocuments?

7. INFORMIX ESQL/C prepare statement crashes

8. How to setup postoffice for SQL mail in NT4.0?

9. ANN: Asking about DBD::Informix in comp.databases.informix

10. HELP: Compiling DBD::Informix with Informix v5.x HP-UX

11. DBD::Informix and comp.databases.informix

12. Informix and Linux (DBD::Informix/4)

13. SQL Linked Server to Informix - Issue with Update Statement