> > You can only have user management if you have a way to store
> > the user names etc, which involves the security database.
>
> So? Drop security.fdb into app dir (where the fbembeded.dll is) and
> youre done. Actually, right now embedded checks for username so it
> must read it from some system table in db. Now embeded could update

No it does not. The system tables in each database don't include
users.

> just those system tables and skip the security database stuff.
> > > user might want to change the username with which s/he logs in and as
> > > a app developer I have one special case less to worry about.
> >
> > Have you thought about some "users" table in your database? So
> > instead of relying on server side security, do a bit of "roll your own"?
>
> Rolling my own users table isn't solving the problem as FB's login API
> doesn't check it. If you mean that I should behind the scenes log in
> with "generic user" and then ask users to enter username/password
> which I check against "private users table" then this is kind of like
> reinventing the wheel...
>
> The point is that the embeded and remote server should behave the same
> so that developer don't have to distinguish between them.

On which level? If you want them to behave the same, they should
both have proper security, but this isn't the case.

In my opion, the Embedded version should accept the APIs with
regard to security, but they should be void, I guess.

This is something you could ask for in the bug tracker.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com