> Do NOT use ndbm.
>
> That is certainly your problem. I'm starting to regret we ever
> added support for it, and I'm certainly regretting that we didn't
> include some larger warnings in the documentation about ndbm's
> heinously limited characteristics, though we did include a
What is so nasty is that the indexing fails silently. I didn't get a
message that I have exceeded the limits so it never occured to me that
ndbm was the problem. (Yeah, I'm still naive, I've only been in this
business 20 odd years... err, pehaps that should be senile)
Would it be worth adding an extra warning to the README file saying
"Don't use ndbm unless you absolutely have to and if you do use it it
may fail silently in mysterious ways" That avoids having to alter the
User Guide.
I saw the warnings but thought "Oh I don't have any of the other db
packages installed so I'll use ndbm in the meantime. If it fails I'll
go and get something else"? As I said before, that it would fail
silently without me noticing, just never occurred to me.
>
> Try it with gdbm or better yet berkeley db and see if that
> doesn't solve your problem. -- Tim
>
What are the advantages of Berkeley db over gdbm? Performance?
If one does use the Berkeley package is there any preference for the
hash or btree implementaions.
I would like to take this opportunity of saying Thanks!! to
The University of Michigan for making this execellent software
available. It has allowed us to get off the ground with this project
and provide us with a server to test mail clients against.
Long term we may buy a commercial server but being able to 'test the
water' cheaply and easily makes a big difference to us.
I would also like to say a personal thanks to Tim Howes who obviously
still maintains a keen interest in the package even though he (at
least from his email address) no longer works for U Michigan. Thanks
Tim and thanks to all the other helpful people on the list.
Cheers and Thanks,
Russell.