How do I name my connection?

[former_SQLA_member1694872]

I am developing an application to perform data replication between one database and another, replication will be done through Trigger. I need to identify which application is performing a certain operation, and through this feature I mean to trigger that if the responsible By changing the application X it will not do anything. Objective: Avoid the infinite loop.

How do I send the name to the connection, would like to pass the name of the executable, to be identified in the process. If it is not possible how do I get the name of this connection when connecting.

See Image

[VolkerBarth]

replication will be done through Trigger.

Wow, SQL Anywhere used with a homegrown replication method - wouldn't the builtin tools SQL Remote or MobiLink do that for you?

FWIW, you can name a connection by using the CON connection parameter, and you can identify an application based on the AppInfo connection parameter. However, it might be more robust to use a different user for that purpose. Note, SQL Remote does use the particular CURRENT REMOTE USER to identify operations applied by the Message Agent (i.e. done through replication) to distinguish those from "normal" activities.

[former_SQLA_member1694872]

Mobililink is very likely to work, but ... the manager wants the "our own replicator" to be made (the words he used).

And now I'm trying to develop the wheel again, anyway ..

By the way, creating a remote user answered my question. Thank you!

[Breck_Carter · Accepted solution]

The connection can be given a name with the ConnectionName (CON) connection parameter; for example:

"%SQLANY16%\\bin64\\dbisql.com"^
  -c "ENG=ddd16;DBN=ddd16;UID=dba;PWD=sql;CON=ddd16-2"

The connection name can be retrieved inside a trigger using the CONNECTION_PROPERTY ( 'Name' ) function call; for example:

SET @connection_name = CONNECTION_PROPERTY ( 'Name' );

See List of connection properties.

The CREATE VARIABLE statement can be used to create connection-level user variables that pass data down to triggers. These are very useful since triggers don't have arguments and parameters. They are sometimes called "global variables" because the values are available to all SQL code running on the one connection.

Question: Why are you building your own replication? I understand that SQL Remote and MobiLink have their limitations, but it is strongly suggested you use them as a transport mechanism... they solve many many many many many problems you will run into. For example, I recently used triggers on ASE and ASA to port a large Replication Server application over to MobiLink without losing the "operation-level" nature of the synchronization (MobiLink does row-level, SQL Remote does transaction-level, neither works exactly like Rep Server, and this App From Hell had its own ASE and ASA triggers that wanted to see every single replicated insert, update and delete).

[former_SQLA_member1694872 · Accepted solution]

Answering your question: Mobililink works, I was directed to develop "our own replicator". Thank you!

[VolkerBarth · Accepted solution]

I was directed to develop "our own replicator".

Our thoughts are with you.