This is a topic I'd like to hear more about too!

At Capilano College, we have some experience with this.
I haven't looked at disk space.  As to performance, there
is certainly some overhead when you go through the Allbase
layer to get at your Image data.  Then there is the additional
layer of ODBC + network.  I think the first of these is the
bigger one.

The worst problems we had:  the SQL optimizer is supposed to
use Image paths intelligently, but it may need some help.
For example, we have a detail set with two paths whose average
chainlength differs greatly (6 vs 5000).  An entry can be
uniquely specified using both items.  When searching for such
a record, SQL was using the long chain, regardless of how you phrased
the SELECT and regardless of which was the Image primary path.
The fix was to "update statistics" using ISQL.

The other thing to watch out for is locking - if you're not careful,
Allbase will place many locks, which may conflict with your Image
locking strategy.

Another problem we've had, using the 16 bit ODBC driver: a user
accidentally used MS Access to perform a query, not realizing it
would do the infamous "outer join".  This can easily happen, but
the Allbase listener job (running in CQ) took over the machine to
such an extent that it was almost impossible to kill it.

These problems aside, we're finding that it's quite feasible to
use PC apps (Powerbuilder) with ODBC to get at the Image data.

Good luck!

                      -mike freeman-


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.