> Alan McDonald wrote:
> >> One idea I had a while ago to bypass the service manager.
> >> Create an extra table to temporary store the user/password until
> >> replication, of course decent encrypted. After table replication, the
> >> password is changed by decrypting the field (via post event or kinda)
> >> and the data is cleaned on both servers.
> >>
> >> HTH
> >> Radu
> >
> > and this extra table is not accessible. you don't have access to the
> > database. The service manager will not provide such access either.
> > Alan
>
> 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...
>
> Radu

the trouble I see here, is that you need to use the services manager to add
a user to the real security db, then a separate action (normal connection +
SQL) to store the same details into another database. You can't use two
phase commit for this (SM can't be a party to 2 phase commit) so there is a
risk that you will have data stored in one database and not the other.
Next there is the lowering of security , having plain text passwords stored
in another database.
One idea I had (not tested) is a trigger hack to security2 to store user
details into an external table. This external table is also an external
table of another database. not usre if this is possible. If it is possible
you would have fully encrypted passwords in the external table able to be
replicated. But you can't delete rows in this table, only select and insert.
dropping will be prone to exceptions since the security2 db will have it
open.
Any way I look at it replication is impossible without serious lowering of
security.
Alan