ANSI-Dabase question
Posted in 1999
Topics: Connectivity: ODBC / JDBC / .NET, Transactions, Locking & Isolation
Hi, a customer uses Online 6 on a SUN. Since this is my first customer using an Informix backend, so I am not experienced in this. My applications need ANSI-mode-databases. After setting up an Informix database in ANSI-mode, I have these problems: a) It seems to be impossible to make tablenames public, there is no create public synonym. Each user has to built a list of private synonyms. Is this correct? b) Is it possible to set the isolation level diffent then RR (which is default on ANSI-databases) so that it takes effect for all connections? I do not want to make a call to SET ISOLATION in every application. c) I use CLI to connect to this database form CGIs via ODBC. There seem to be lots of problems when the actions of the CGI become more complex: Some statements do not work (function sequence error). When firing these statement against the database directly using ODBC (e.g. from ACCESS) they work. Any hints welcome! Benedikt
Benedikt Wismans wrote: > a customer uses Online 6 on a SUN. Said customer needs to be upgraded pronto. > Since this is my first customer using an > Informix backend, so I am not experienced in this. > > My applications need ANSI-mode-databases. After setting up an Informix > database in ANSI-mode, I have these problems: > > a) It seems to be impossible to make tablenames public, there is > no create public synonym. Each user has to built a list of > private synonyms. Is this correct? More or less. The usual way around the problem is to ensure that the applications are all written to reference "owner".table at every point and then you don't need to have the list of private synonyms. > b) Is it possible to set the isolation level diffent then RR (which > is default on ANSI-databases) so that it takes effect for all > connections? I do not want to make a call to SET ISOLATION in > every application. Not that I know of. But this is where standardized startup routines are darn useful. If every applications calls a std_options() function, then you only have to do this once, inside that function, and everybody benefits. You can also use this technique to deal with choosing a database, setting SET EXPLAIN ON, capturing database type information (OnLine vs SE, logged or not, MODE ANSI or not, etc), and simple things like security checking. > c) I use CLI to connect to this database form CGIs via ODBC. There > seem to be lots of problems when the actions of the CGI become > more complex: Some statements do not work (function sequence > error). When firing these statement against the database directly > using ODBC (e.g. from ACCESS) they work. Any hints welcome! I don't understand this question, so I can't answer it. CLI is ODBC. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>