Hi, Geoff:

Really appreciate your response, thanks!
(BTW, got that backup system of yours (DBak) to work just fine on my
wife's testing/evaluation program.)

So, the bottom line is pretty much your last comment:

Basically, bring in the encrypted data and decrypt within the client app,
which is what I've done for the previous app.

Then you state:

eg: Implement something like a full text search engine over

> your secret data (where the index may be encrypted or not,
> exist on the database or not). Appropriately implemented it
> may allow you to map search requests into specific (primary key
> based) row requests and so boost performance. A fair bit of of
> work I suspect, but it depends how important the performance
> issues are likely to be. (And if full-text search is already
> a desirable feature then it may indeed be worth while.)

I'm afraid I'm not familiar with this idea at all.

Some points:

If I encrypt "String" with let's say BlowFish then encrypt "This sentence
has the word string in it." I believe the word "string" would have a
different encrypted text in each, thus my problem with understanding how
to index such information for a text search. This type of index should
work for character fields, right, but not BLOB text?

Unless you're talking about the very simple char substitution method for
encryption.

What do you mean by "implement a full text search over my secret data?"
What does this entail? Can you flush out your thoughts here a little more
so I can get the idea?

It sounds like right now the text search of the BLOB text is the real
issue. There will be about 20-60,000 records of which about 50% will have
a text description of the item (a node in a treeview). The description
will be about 100 to 3000 words each. Do you have a sense of how slow it
would be to decrypt each BLOB and continue the search for this scenario
(2 ghz system with 512 mb of ram)?

Thanks again for your article and your response,

Chuck