Re: web databases & CGI

Kalveer Whats the problem? One common problem is that your program is not able to find the database - you need to set the PATH, INFORMIXDIR, INFORMIXSERVER and ONCONFIG variables, either in a script that will call your CGI program or using the configuration variable SetEnv (in Apache). HTH Sujit Kalveer Heer <kal.heer@virgin.net> on 11/15/99 10:12:24 AM Please respond to Kalveer Heer <kal.heer@virgin.net> To: informix-list@iiug.org cc: (bcc: Sujit Pal) Subject: web databases & CGI Can anyone help? I'm trying to connect to an Informix Databse over the web using CGI scripts programmed in ESQL? Has anyone had any experience in doing so? I'm running the application on an UNIX environment. Last resort!!! cheers!

Its an odds-on bet that environment is the problem. You might need to add LD_LIBRARY_PATH to the list of variables Sujit suggests, unless you are using statically linked programs or have $INFORMIXDIR=/usr/lib. In my experience, ONCONFIG is not important with current servers; the others are. Also, there is a PassEnv directive in Apache; however, you should concentrate on SetEnv. Sujit.Pal@bankofamerica.com wrote: > Whats the problem? One common problem is that your program is not able to find > the database - you need to set the PATH, INFORMIXDIR, INFORMIXSERVER and > ONCONFIG variables, either in a script that will call your CGI program or using > the configuration variable SetEnv (in Apache). > > Kalveer Heer <kal.heer@virgin.net> on 11/15/99 10:12:24 AM > > I'm trying to connect to an Informix Databse over the web using CGI scripts > programmed in ESQL? > > Has anyone had any experience in doing so? > > I'm running the application on an UNIX environment. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>

On Tue, 16 Nov 1999, Jonathan Leffler wrote: >Its an odds-on bet that environment is the problem. > >You might need to add LD_LIBRARY_PATH to the list of variables Sujit >suggests, unless you are using statically linked programs or have >$INFORMIXDIR=/usr/lib. Hmmm; I was mis-thinking late at night. You'd probably need INFORMNIXDIR=/usr and even then it probably wouldn't find the shared libraries in /usr/lib/esql. So you do need to use static linking of your programs, or you need to set LD_LIBRARY_PATH. Or... --------------------------------------------------------------------------- ...Or you need to specify the absolute pathnames of the shared libraries on the linker line rather than (or, strictly, as well as) letting the esql script use the relative names. Note that if you do that (sepcify absolute names), you cannot move $INFORMIXDIR because the executable will expect to find the libraries where it found them at link time. This is a complex area, not least because different o/s have different extensions, environment variables and even semantics. However, I'll describe the SVR4 (Solaris, Linux) variant, and you 'll need to modify what I say for other o/s such as HP-UX and AIX. If you compile code with shared libraries using: cc -o prog object.o -L$LIBDIR -lname then at run time, the LD_LIBRARY_PATH environment variable will be used to locate the library libname.so. This means that you can move libname.so to a new location after you've linked the program; and if you place libname.so in /usr/lib, then you do not need to specify anything in LD_LIBRARY_PATH. Also, set UID programs will only ever look in /usr/lib -- a basic security precaution. If you compile code with shared libraries using: cc -o prog object.o $LIBDIR/libname.so then the run time loader will always look in $LIBDIR/libname.so, where the value of $LIBNAME is evaluated at link time, not at runtime. This also means that you do not have to worry about setting LD_LIBRARY_PATH or about set UID programs. However, it also means that you cannot move libname.so. The 7.1x versions of ESQL/C use absolute names for the shared libraries. As long as you linked your code on the machine where it was going to be used and did not try to move $INFORMIXDIR, this worked well. However, if you want to write code that can be installed anywhere, this is problematic. The 7.2x versions of ESQL/C use relative names for the shared libraries. All the ClientSDK versions also use relative names. This allows you to link your code on a development machine with $INFORMIXDIR in one location and install the code on a production machine with $INFORMIXDIR in another location. However, it also requires that the LD_LIBRARY_PATH environment variable is set. I'm now of the opinion that we need the esql script to provide options for either absolute or relative shared library names (eg "-shared -absolute" and "-shared -relative" with "-shared -relative" being the default). FWIW, the next version of DBD::Informix will rig the linking process to use the equivalent of '-absolute -shared' unless the user overrides this. Of course, this is an area where other people have opinions. One of the key influences on my thinking is the paper "Why LD_LIBRARY_PATH is bad" (URL http://www.visi.com/~barr/ldpath.html). However, I've now had experience with Solaris and the -R option and LD_RUN_PATH environment variable, and with Linux and /etc/ld.so.conf, and with AIX and dynamic loading of shared libraries, and these have convinced me that for most people, most of the time, "-shared -absolute" is a sensible way to go. I was one of those who argued that the version 7.1x ("-shared -absolute") method of linking was the wrong way to do it. In the context where I needed to use it, it was a confounded nuisance; if you tried to build I4GL with ESQL/C shared libraries and those libraries could not be relocated on the customers machine, you have a problem. That means that I partially repent of my previous view that it was the wrong way to do linking. I think you need both options; I4GL would still need the "-shared -relative" option (or would have to use static linking, or would have to link programs using ESQL/C libraries on the target system), but for many purposes, it is better to use "-shared -absolute". --------------------------------------------------------------------------- >In my experience, ONCONFIG is not important with current servers; the >others are. > >Also, there is a PassEnv directive in Apache; however, you should >concentrate on SetEnv. > >Sujit.Pal@bankofamerica.com wrote: >> Whats the problem? One common problem is that your program is not >> able to find the database - you need to set the PATH, INFORMIXDIR, >> INFORMIXSERVER and ONCONFIG variables, either in a script that will >> call your CGI program or using the configuration variable SetEnv (in >> Apache). >> >> Kalveer Heer <kal.heer@virgin.net> on 11/15/99 10:12:24 AM >> I'm trying to connect to an Informix Databse over the web using CGI scripts >> programmed in ESQL? >> >> Has anyone had any experience in doing so? >> >> I'm running the application on an UNIX environment. -- Yours, Jonathan Leffler (jonathan.leffler@informix.com) #include <disclaimer.h> Guardian of DBD::Informix v0.62 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

Cheers Jonathon I am statically compiling my esql/c program..and its doin something ie the script doesn't return any errors but it still can't connect to the db? I'll try sourcing the Informix Env's..but if i can't get that to work today...i'm gonna throw the machine out the window! ------------------------------------------------ Signing OUT! Email: mailto:ksh@cs.bham.ac.uk WWW:http://www.heer.org.uk

I've included some sql error checks and when the cgi program is executed i get an sqlerror in my logfile: Testing CGI program ===================== Run at: 10:21:33 on 17/11/1999 opening database ksh_db@informix connecting to db sqlcode -461, isam 0 Sql: Unable to load locale categories. i've checked the error...and am a bit dazzled? -- ------------------------------------------------ Signing OUT! Email: mailto:ksh@cs.bham.ac.uk WWW:http://www.heer.org.uk