Claudio,

> Hey, in real world, do not use this nasty relative path
> (corruption awaits
> for you), it was only a quick typing in my single user
> session, you should
> use something like
> gsec -database localhost:disk:/full_path/isc4.gdb -display
> instead. Here's a full example with a fictitious user:
>
> gsec -user locksmith -password backdoor -database
> localhost:localhost:f:/bd/borland/interbase/isc4.gdb -display

LOL, a fictitious user!

I like your cynical humour ...

The locksmith user is hardcoded in interbase itself, so why shouldn't
I hardcode it again im my application ;-)

Hey, in real world, I wouldn't like to hardcode any username or password
in my application - even using encryption.

So it seems the best way to use the Services API or to sync the ISC4 with
the production DB once (application start).


Thank you to everyone.


Christian

> Use localhost or the target machine's name only once! I was
> having fun with
> the IB multi-hoop ability when I specified localhost two
> times, but beware I
> found it very easy to leave the server hanging with this old
> multi-hoop
> feature. So, the final string looks like:
> gsec -user locksmith -password backdoor -database
> localhost:f:/bd/borland/interbase/isc4.gdb -display
>
>
> > Due to the fact that new users are not added very often and
> only SYSDBA is
> > able to change their passwords, it shouldn't be risky to
> proceed in this
> > way.
> >
> > What do you think?
>
> It depends. Accessing the security db is not the best
> thing to do, but
> since you are only reading, there's no great problem. Anyway,
> either you
> hardcode its location or you call another Services API entry
> point to get
> the location of the remote security db.
>
> C.
>
>
>
>