Re: No ODBC access to Informix...

wolf.duttlinger-manger@gmx.de (Wolf) wrote in message news:<6e942e26.0411080636.4fc52fc4@posting.google.com>... > Hello all, > > after googling I saw that the same discussion came up in 1997/98 - but > did not lead a satisfactory result for me.... > > Situation: > We have some kind of a pre-fab ERP solution in house. From any PC a > telnet session is used to connect to the Solaris and to start the > application. > > The application uses the Solaris user ID to identify itself to the > database - and hence there are certain rights, that those users have. > E.g. a user may well have the right to change a record using the > application interface's business logic - BUT may not have the right to > change a row arbitrarily. > > So far reporting has been done using MS Query/ODBC. Of course any user > could simply go in MS Query and generate any SQL code - basically > allowing him/her to circumvent the application's business logic.... > > I do not know Informix - but from my understanding there must be a way > to totally disable ODBC access towards this database. I know a little > about DB2 and Oracle and from there I have the following picture: > > - every box may have one or more instances of a database "engine" > - every engine may manage one or more databases > > Is it like this with Informix (5.01)? Is there a "listener" per > engine, that can be tweaked the way I want it? > > We want to create a "report" DB - either on a seperate machine or - > preferably - on the same machine, where MS Query access would be > allowed.... > > So my ideal picture looks like this: > - one Solaris box > - two instances of Informix loaded > --- one w/o ODBC access > --- one w/ ODBC access > - every instance managing one DB > - applying the "redo"-logs of the w/o ODBC engine towards the other DB > gives a time-shifted "copy" of the production DB. > > Does this make sense at all????????????? > > Any postings appreciated! > > Regards > Wolf Duttlinger-Manger Wolf, The problem that you are having is basically at the epicenter of what I call "post evaluation" (pilot or rollout stages to be precise) ODBC challenges. You have a Line of Business (LOB) application (in this case the ERP system) that interacts with Informix in a manner controlled by the application that works fine. But you also have ODBC access to the same Informix DBMS driving this system which introduces concurrency, security, and other DBMS usage issues. Assuming my analysis is correct, then OpenLink Software does have a solution for anyone using ODBC (Informix and other databases) that finds themselves in this predicament. Our solution is offered via a feature called a "Sessions Rule" book that is part of our Multi-Tier ODBC Driver format. The Rule Book basically allows you to set rules that are enforced across all OpenLink ODBC sessions (this doesn't apply to none OpenLink ODBC Drivers). For example you could have a rule that states that when MS Query hits Informix the session should be read only, while other applications (or your ERP application explicitly, if ODBC based)operate in read-write mode. For additional information visit: http://uda.openlinksw.com/odbc/mt/ You can also study the OpenLink ODBC product documentation at: http://docs.openlinksw.com/mt/oplsessadminconf.html BTW - We implemented this functionality back in 1993 when we commenced the development and deployment of ODBC Drivers for all major DBMS engines. In addition to performance and scalability, this is how we distinguish our drivers from alternatives. Kingsley Idehen OpenLink Software http://www.openlinksw.com/blog/~kidehen