Re: DBD::Informix

> > OK. That means your ESQL/C installation is dubious. Which other > ESQL/C programs have you successfully compiled with it? I grabbed the latest version of csdk.cpi (which has a date of March 2004, I think) and did the cpio to unpack it and did the ./installclientsdk thing. It installed just fine. 2.81.UC3 (953). I installed sqlcmd 72.06 on the shirttails of this CSDK and sqlcmd now works fine! (Over the winter, I had to use a version of sqlcmd compiled on RedHat 8 and run it on RedHat 9 with the LD_ASSUME_KERNEL env variable set to 2.4.1, but I no longer need to do that). > Which version of which o/s are you using? RedHat 9 > > Which version of Perl, DBI, DBD::Informix, ESQL/C (or CSDK), IDS (or > other Informix DBMS) are you using? Perl 5.8, DBI 1.43, DBD::Informix 2003.04, CSDK 9.53, Informix (server) 7.x on HP_UX 10.20... > Of these, the o/s and the ESQL/C versions are currently critical; the > C compiler that you're using might also be material... I'm using the gcc compiler 3.2.2 > The processor speed is almost entirely immaterial, and the memory is > also likely to be immaterial - I develop DBD::Informix on a 333 MHz > machine with (IIRC) 256 MB memory. I didn't think that would really be the issue, but it was the only obvious difference between the two boxes (aside from local files and disk space, etc). I've never heard of problems with ESQL/C crashing on variations of > CONNECT. I've heard of all sorts of other problems, but not crashes. > In the circumstances, we should start by analyzing the platform and > CSDk versions. When that turns out to be immaterial or current, then > we start really scratching our heads...but we also test with > esqlbasic.ec (distributed with DBD::Informix) to see what goes. The > primary advantage of that is that it is even simpler and hasn't got > any Perl in it at all. We'll probably end up upgrading it to play > with variants of CONNECT (it uses DATABASE statements so it can work > unchanged with ESQL/C 5.x as well as later versions), but ... > I don't know about you, but I've already started with scratching my head. If I were bald, it certainly would be self-induced. I'm ready to try something else! ;-) esqlbasic.ec works just fine. esqltest works through the first connect just fine, but "segmentation faults" on the CONCURRENT connection attempt. Is this a permission issue with the server allowing only one simulataneous connection? (No, then it wouldn't work on the other box, either.) Hmmm. I'll try bringing over esqltest from the box that works and see if I get anywhere that way... Thanks for the help! I'm hopeful you continue to stick with me to see this problem through resolution! Mark