Re: Is ESQL my only option ??

: I'm thinking about the same solution that you suggest above. But I have one : problem with it. How should I implement functions f'r the select statement. : I know that I can use dynamic ESQL/C to detect the structure of a table at : runtime. This is not the problem. But I need a general way to build the : SELECT-statement at runtime for different databases. First of all I would point out that building select statements and communicating with a database server are two separate problems. Even if someone else generated your queries for you you would still need to be able to submit those to a server, handle errors, retreive results, etc. Secondly, sql is fairly standard and needn't be changed for most databases. There are certain operations where this isn't true (i.e. outer joins), but perhaps you can get by without performing these? If you do need a generic way of specifying these operations, you could take the ODBC approach which is to use a sql translator which parses the sql, then translates it into something vendor specific before sending it to the server. : Which experiences do you have made with your C-API??? Do you miss SQL??? Can : you give me a hint about your functions for selecting data out of tables??? My api is used mostly by our OLAP engine which performs it's own calculations. This means that most of what I get from it are select statements which are handled by any ANSI standard server. My api does not replace sql, it offers a level of abstraction to the client program so that the client need not be concerned with what type of database it is working with. Hope this helps. Kurt Mehlhoff Software Engineer Information Advantage kurt@infoadv.mn.org 7401 Metro Blvd. Ste. 500 uunet!tcnet!infoadv!kurt Edina, MN 55439 (612) 820-3840 (612) 820-0712 FAX