Subject | RE: [Firebird-Architect] isc_add_user, et al |
---|---|
Author | Claudio Valderrama C. |
Post date | 2003-12-30T11:03:35Z |
Jim Starkey wrote:
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.
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.
C.
> Even worse than I thought. First, the account functions return anI only read your message today. Days ago, I made them return ISC_STATUS.
> "int", unlike everything else, which returns "ISC_STATUS" (aka
> "long").
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.
> Second, the miserable functions don't take database handles.In your original design, was there something like db-specific accounts?
> 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.
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.
C.