Re: c program against databases

One approach would be to structure your code so that the database accesses are separated out from the bulk of the application logic and kept in a separate source file. You could then have alternative versions of this file for different databases. That would help manage the code side.

Keeping different versions of the dev packages is a complex issue. If you supply a shrink-wrapped product to the customer you may be including proprietory code from the database vendor (unless the customer is responsible for providing the shared engines and any proprietory shared libraries). In this case you are acting as a reseller for the database vendors and will need to establish a suitable commercial relationship with each of them. If, of course, the vendors see your product as a vehicle by which their sales also benefit then they may (OK, ought to be) pleased to supply you with the development systems.

Ian

Lan H. Tran wrote:
>
> hello,
> i would like to write a unix-based c program that would perform SELECT
> and INSERT against a database. i am very familiar with esql/c.
> however, i would like to productize this program and allow it to work
> with a variety of databases (Informix, Oracle, Sybase, DB2) on a variety
> of operating systems (variations of unix and NT, maybe).
>
> is the best way to write embedded sql c code (and recompile using
> esql/c, pro*c, etc...)? how standard is this? is there a good toolkit
> to help me out? is there a good book or website to learn more? how do
> app dev packages like IEF do it?
>
> it seems like i would have to buy alot of precompilers. for example, 4
> databases running on 5 platforms would require 20 (4 x 5) esql/c like
> compilers. is this true?
>
> i would appreciate any guidance.
>
> Lan H. Tran
> Ventera Corporation
> lantran_at_ventera.com
  Received on Sun Mar 16 1997 - 00:00:00 CET