Re: database independence

Hi Just to add something to the conversation, beware of the various informix modes (buffered, ansi etc) We have a case over here in New Zealand where a customer has an informix ansi database with our application (RIS) talking to it. The customer also has another informix database which is created with non-ansi mode. And have another third party program running on this. The problem is they want both the databases to talk to each other online. Our application must talk to an ansi informix database. And the customer's other application only talks to informix non-ansi mode database. So we cannot standardise the customer to informix ansi mode database. We NEED both the informix modes database to talk to each other. BUT apparently this is impossible? Talking to informix locally says it cannot be done. Surely there must be some way to do this with informix? I would greatly appreciate if somebody could tell me I was wrong The RIS product has been written to be database independant with programming tools available for it. (it talks to Informix ansi, oracle, sybase,ingres,rdb, db2). You may wish to use RIS to may your application independant of database. We are hoping that ODBC may resolve our problem. Ta Brent Rankin Support Engineer Auckland New Zealand } } brrankin@auckland.aussy.ingr.com } ingr!aussy!auckland!brrankin } } } Forwarded message: } > From uucp Sat Feb 5 06:11 CST 1994 } > From: owner-informix-distr@timtow (David Clegg) } > Message-Id: <CKMG9K.2JI@sybase.com> } > Subject: Re: database independence } > Date: Thu, 3 Feb 1994 00:05:44 GMT } > Reply-To: davec@ribo (David Clegg) } > Organization: Sybase, Inc. } > Sender: owner-informix-distr@timtow } > To: informix-list@rmy } > X-Informix-List-To: informix-distr2@timtow.b1.ingr.com } > X-Informix-List-Id: <news.5439> } > } > The suggestion that you layer your application to isolate the RDBMS access } > in separate modules is a very good one, but do not confuse that with the } > other issues. I would recommend that if you can implement your project using } > ANSI '92 Entry level ESQL, you should go ahead and do that. } > All ANSI certified ESQL precompilers have a mechanism known as FIPS-FLAGGING } > which you can use to identify any non-standard extensions you are using in } > your ESQL. } > } > If you can get a 'database independent' version of your application running in } > this way, you can worry about optimizing performance for specific databases } > later -- as the performance bottle-necks and market demand direct you. } > } > } > In article <cwhite.94Jan1313375@guava>, christopher.white@mccaw.com writes: } > |> The problem with programming down to the lowest common denominator is } > |> that you get the lowest common denominator. Different databases have more } > |> advantageous ways to do different things. Database independence is important, } > |> as is hardware independence. My advice is to separate all of your database } > |> calls through a couple of layers of abstraction. Then, your F/E simply calls } > |> a function and gets data back. This should de-couple the database relationship. } > |> By using two layers of abstraction, you can get some additional scalability and } > |> independence (e.g. you can use a distributed architecture or a monolith architecture). } > |> } > |> Good Luck, } > |> } > |> } > |> Topher } > |> --- } > |> Christopher A. White | "I once could see, } > |> McCaw Cellular Communications | but now, at last, I'm blind." } > |> Kirkland, Wa | -- Dream Theatre } > |> } > } > -- } > Dave Clegg -- davec@sybase.com } > } } } -- } Regards } } Brent Rankin } Support Engineer } Auckland } New Zealand } } brrankin@auckland.aussy.ingr.com } ingr!aussy!auckland!brrankin } Phone: 64-9-3661712 Fax: 64-9-3661715 } -- Regards Brent Rankin Support Engineer Auckland New Zealand brrankin@auckland.aussy.ingr.com ingr!aussy!auckland!brrankin Phone: 64-9-3661712 Fax: 64-9-3661715