At 05:43 AM 9/07/2006, you wrote:

>I'm evaluating a commercial Rails application for use against a
>Firebird (ver 1.5.3) database. The application throws segmentation
>faults when run against Firebird vs. Mysql; also, the Rails unit tests
>throw segmentation faults (for me) against Firebird. However, my own
>small test projects in Ruby (using FireRuby) and in Rails (using the
>Firebird adapter that ships with Rails) run flawlessly. Are segfaults
>with Firebird and Rails a problem that other people are facing?

I've dabbled with Ruby so far and with Rails not at all, so my
suggestion here doesn't have to do with Ruby/Rails specifically...

I don't know how the Firebird-Ruby interface has been done,
either. However, one source of segfaulting might be due to using the
wrong Firebird client library in the mix. There are two.

-- libfbembed.so is a local-only, direct-to-database client that can
be used with Fb Classic for server-only applications and, e.g. can be
used to connect isql to a FB Classic database locally. It will cause
segfaults if you try to use it with Superserver

-- libfbclient.so is the remote client that should be used *always*
with Superserver and when connectly remotely (including locally via
localhost) to Classic. But you will also get a segfault if you
attempt to connect remotely to Classic using libfbembed.so.

So I'd want to be examining the "mix" to see what the commercial
application is connecting to, vis-a-vis which model of Firebird
server you are running. It might not be as easy as checking library
names...track through any symlinks...there are various possible
complications, in combination or not, such as

-- the application implementor (or FireRuby itself) might be a
complete re-implementation of one or the other library, thus
restricting you to use one specific server model

-- one or other of them might be symlinking one or other (or both)
client libraries locally and/or at the server as "libgds.so" to allow
compatibility with either Firebird 1.0 or Interbase (both of which
use the *same* library name for both versions!)

You don't say which version of Firebird you're working with but, if
it's one of the Fb 2.0 betas, it could be that the commercial app
isn't "aware" of the changes in authentication there. In the same
area of suspicion might be that the app was developed over Fb 1.0,
which doesn't hold a write lock on the security database...

>BTW, I love how Firebird delivers sophistication and performance in a
>beautifully simple package!

And it's great when third parties pick up Firebird and provide
side-by-side support in MySQL's territory. If you do in fact
discover that the trial app has some built-in, undocumented model or
version usage limitations, be sure to write it up and forward it to
the developer. It's not necessarily always the case that the
implementor is fully clued up on the differences between Classic and
SS. You might even get a freebie out of it!

./heLen