Guido Klapperich wrote:

>> The table is in the database replicated, not in the security2.fdb.
>> Now that you mentioned, one could use an additional database, just for
>> this purpose, in case of multiple database replication.
>> I know it is not the most elegant solution, but it might work...
>
> Yes, that's a possible solution I have also been thinking about. But
> that could only work, if a user changes his password only by my app.
> Then I can log the password change.
> For example a user USER1 changes his password in the headquarter by my
> app. I have to log, that USER1 has changed the password and I have to
> log the old and the new password. Now user REPL starts the replication
> from a laptop. The replication process then have to change the password
> at the local security2.fdb on the laptop. Therefore the process has to
> make a api call to update the password as user USER1 with the old
> password and change it to the new one.
> I don't really like this solution, especially that I have to store the
> old and new password, but it seems to me the only way.

Yes, it must be done through local api calls, either your application or
some replicator.
I think the security isn't THAT lowered i you delete the new password
row after change, this is the way to test for a password change,add user
,delete user.
Other idea, which I don't think it will work is to have some udf to do
the api calls and call udfs by triggers in the extra table

Radu