CURRENT REMOTE USER in MOBILINK

[Baron]

According to the docs, CURRENT REMOTE USER is used only in SQLREMOTE.

Doesn't this work in MOBILINK too (at least by DBMLSYNC)?

Is there any other alternative for DBMLSRV too?

Sorry, I couldnt have time to try it, and just wanted to have a quick answer from the Gurus!

[regdomaratzki · Accepted solution]

CURRENT REMOTE USER is specific to SQL Remote only.

In the ML Server, you can use the {ml s.remote_id} or {ml s.username} system parameter in your synchronization scripts.

Doc Links :

• Named script parameters
• MobiLink system parameters and events

For dbmlsync, you have access to the MobiLink User that is synchronizing in many of the Event hooks for SQL Anywhere clients.

Reg

[VolkerBarth · Accepted solution]

Additionally, you may use a particular database user when connecting via mlsrv to the consolidated to distinguish that from regular connections to the consolidated. This will do if you just have to distinguish remote and local modifications, it obviously won't do if you need to distinguish between modifications by different remote databases. In my experience the CURRENT REMOTE USER is used for both cases in SQL Remote environments...

[Baron · Accepted solution]

If we are talking only of SQLRemote, then CURRENT REMOTE USER is useful (not replacable) only on the Cons. (becuase it can tell me whether the transaction is local or remote, and additionaly, it tells me from which specific Remote is this transaction coming).

On the Remote side, (if I assign a particular user for DBREMOTE), then I am able to distinguish whether the current transaction is local or is received via DBREMOTE (i.e. from the Cons. DB), (so assigning a user for DBREMOTE can replace the job of CURRENT REMOTE USER)!

In my understanding I can have only one Cons. in SQL-Remote installation! Am I right?

Also in Mobilink installation, I can have only one single Cons. (i.e. only one Mobilink server to each Mobilink Client)! Am I right?

[VolkerBarth · Accepted solution]

As to the only one consolidated database, yes, that's generally true for each remote. However, there are environments with more than two levels/tiers, so a SQL Remote condolidated can itself be a remote for a higher level consolidated. But even then each single remote has just one (direct) consolidated.

We have also used CURRENT REMOTE USER on the remote to distinguish between local and remote operations (the latter of course then coming from the consolidated) - in my experience it was often enough to use something like "IF CURRENT REMOTE USER IS [NOT] NULL" within trigger code, and for that it only matters whether operations come from a remote or not, not from which remote. Therefore my suggestion that within ML, you simply may use a different userid for the ML server connection if that is enough.

[Baron · Accepted solution]

OK, thank you very much.

We already have several (multi tier) installations with Mobilink and also with SQLRemote.

Everything is clear!

Have a nice (and healthy) weekend!