--- In ib-support@yahoogroups.com, "Ben Johnson" <ben_johns@r...>
wrote:

> Hi,
>
> Can somebody explain me the real benefit of using C API to talk
> to FB over other components. Pls explain it seperately for client,
> server and network.

I think those who've already responded to your post have answered
the question quite well, but I'll chime in anyway for what it's worth.

I've written quite a bit of C code against the Firebird C API, and I
wouldn't recommend using the C API directly for 99.99% of
applications. I'd estimate that with a good high-level wrapper, you
can accomplish the same thing in 20 to 30 times less code. That's not
an unfounded assertion; it's based on my experience with
Python-kinterbasdb vs. C-native.

Additionally, some of the aforementioned "high-level wrappers"
implement a standard database API (Java-JDBC, Python-DB-API, etc.),
which will give your application some degree of portability to other
databases.

The performance advantage of application code written directly to
the native C API is not as significant as it might first appear. That
advantage lies chiefly in minimizing the time spent converting
database-native values into values usable by the application, and back
again. In typical applications, however, database-value-conversion
time is dwarfed by the time spent on:
- network and/or inter-process communication
- aspects of the application not specifically related to the database
layer

So in practice, the performance difference is rarely worth the extra
effort. It would not be terribly difficult to come up with a
benchmark that contradicts this assessment, but the benchmark would
bear little resemblance to the typical database application. If your
planned app is in this category, then by all means use the raw C API.

Another consideration is whether the high-level framework you might
use in place of the raw C API supports all of the features you need
(database events, Services API, database arrays, ...). Many of the
high-level frameworks are somewhat narrow in scope.