David,

Thank you for the reply.

I am currently using IB 5.6 as the database engine. I am running on Win98 and chicken to mess with a development environment for
systems in production. If blobs are in InterClient 2 for IB 6.0 I will start up another development environment for that.

I am using Java 1.3.1. I have downloaded what I believe to be Java client code, posted by Alejandro Alberola Arias, at
http://groups.yahoo.com/group/IB-Java/files/
I believe this will eventually talk directly to the Interbase engine on port 3050. I have compiled the code but cannot yet connect
to a local Interbase 5.6 database (maybe it needs IB 6.0).

I have not seen the InterClient Java source files, I will go look for them and compile them under jdk 1.3.1 as an interim approach.

Finally, your thoughts on XML. I agree that the use of a blob and the xml structure embedded within the blob will prevent me from
directly searching within that body of data. The application is for a cancer researcher. He needs a degree of freedom to express the
protocol details, as they evolve over time, in the collection of data. We are looking to remove the programmer from the loop (me).
He also needs to document any changes made to any recorded datum over time. I am exploring XML as a more flexible yet structured
description of the "data schema". I've considered, for indexing within the xml, another table containing roughly three columns:

1) the id of the blob row (it has a unique id) as a reference
2) the path through the xml document to get to the datum being indexed in this row
3) the datum

I'm still thinking hard about Column 2 above.

I figure some kind of tool, driven by the researcher, would step through the XML records extracting the paths he selects and storing
them in the above table. It would be nice to have Java on the server to handle triggers when the blob is updated!

Bill