Hello All,

First let me say that I very much appreciate your interest in this topic.

My main concern about the C API is the code that needs to be written
by each developer every time it is used. This code has to accomplish
the same basic thing over and over again. This dramatically increases
that potential for memory leaks and other bugs. The main goal of my post
was to suggest that the major problem areas could be identified, and a
fairly simple and unobtrusive set of convenience functions could be
written.
This code could be written once and stabilized. This would increase the
overall quality of applications that choose to use the C API and
hopefully
encourage other applications to support Firebird as a database back-end.
I don't believe the Firebird database receives the attention or wide
spread
use the it really deserves. I think this enhancement could serve to
eliminate
at least one potential reason for this.


I believe it is critical to avoid any impact on existing API users. Even a
subtle impact on existing users would defeat the entire motivation for
enhancing the API in the first place.

I am a new user to this API myself. I have written an abstraction layer
for my own use on top of the C API. I may not be qualified to put forth
the best design ideas for this. However. if everyone would keep this in
mind, I don't mind sharing my thoughts. The following ideas are based
on the code that I had to write to implement my abstraction.

1. The DPB

This is certainly an area where the developer is required to manipulate
something in a way that is very clumsy and error prone. Usually when
there is a requirement for this type of data interaction, there is some
associated requirement that makes the detail necessary. In this case
I was unable to see the need.

isc_allocate_dpb(char **dpb, unsigned short *dpb_size);

The idea behind this function is two fold. If no size was specified, it
would allocate
some reasonable initial size and make it very clear that memory was being
allocated
and would ultimately need to be freed. The initial size could be based on
what would be
deemed a typical set of parameters.

isc_set_dpb_option(char **dpb, unsigned short *dpb_size, ...)

This function would behave in a similar fashion to isc_expand_dpb(), but
be capable of
handling all parameters types.

2. The XSQLDA

This is another area where it seems there is a lot of redundant code
required by the
API user. I again, was unable to see any advantage of putting the
additional code
requirement on the developer. The potential for error is again, fairly
high.

isc_dsql_allocate_xsqlda(XSQLDA **xsqlda, unsigned short xsqlda_size)

This function would allocate the initial XSQLDA with some reasonable size
if none
was specified.

isc_dspl_prepare_xsqlda(XSQLDA *xsqlda)

This function would handle all of the required memory allocation for both
information
and data. An additional null byte would be allocated for string based
data.

isc_dsql_free_xsqlda(XSQLDA *xsqlda);

This function would free everything.

char *isc_dsql_get_name(XSQLDA *xsqlda, unsigned short colno)
short isc_dsql_get_type(XSQLDA *xsqlda, unsigned short colno)
short isc_dsql_get_length(XSQLDA *xsqlda, unsigned short colno)
...

void *isc_dsql_get_bytes(XSQLDA *xsqlda, unsigned short colno)
char *isc_dsql_get_string(XSQLDA *xsqlda, unsigned short colno)
long isc_dsql_get_long(XSQLDA *xsqlda, unsigned short colno)
...

These functions would be used information and data from table columns.


3. Summary

This is just a rough example of what might be possible without
compromising
the current API. I'm sure there are many alternative ways to solve the
problem.
I am, by no means, suggesting that mine is the only one.

Thanks to everyone for your time and interest,
-G





[Non-text portions of this message have been removed]