Re: database independence

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