Claudio Valderrama C. wrote:

>Jim Starkey wrote:
>
>
>>Even worse than I thought. First, the account functions return an
>>"int", unlike everything else, which returns "ISC_STATUS" (aka
>>"long").
>>
>>
>
>I only read your message today. Days ago, I made them return ISC_STATUS.
>Really, it was an interface problem. The functions work with ISC_STATUS
>internally. It returns
>status[1] as usual with ISC_STATUS* status. I'm not sure if the change is
>already in CVS or it's still in my pending commit.
>
>

It was checked it. And it bit (well, nibbled) on my left when folding
in the FB2 code. But it was absolutely the right thing to do.

>>Second, the miserable functions don't take database handles.
>>I willing to give the benefit of the doubt to the brain-dead idea
>>that database accounts are system wide rather than database specific,
>>but an architecture makes implementation of a more reasonable option
>>is a little dim.
>>
>>
>
>In your original design, was there something like db-specific accounts?
>Apparently, you defaulted to operating system security only.
>Those functions are marked as deprecated by Borland. They recommend using
>the Services API that has SPB's, that are the equivalent of DPB's.
>
>
>

Security was handled by OS login names with security classes, all of
which assumed a well-managed Unix network with hosts.equiv. But since
in classic, every user required write access to the database file,
enforceable security was particularly possible, so not a high priority.

In my very humble opinion, system wide accounts is one of the stupidest
crocks in the history of the product. It's wrong from every angle other
that it was easy to explain to a Borland exec.

Vulcan will maintain that crock as a default security plug in, but there
is no way that a system with my name on it is going to be restricted to
that sorry excuse for a not-even good faith effort at an intellectually
defensible design. What were they possibly thinking of?