I don't think you can change the information specified in a connection string after the connection has been established (other than do a re-connect).

Besides that, you might use some of the following:

1. If your application username is the OS user name and you are using v11 or above, then the follwoing call will return that user name:

select connection_property('OSUser');

1. You might use a connection-specific variable and fill it from within your application. Such a variable can be used like a "global variable" but is connection-specific.

create variable MyUserName varchar(100);
set MyUserName = 'WhatEverYouLike';

A DBA can create a PUBLIC option, and once created anyone can override it with a connection-level setting; all such options are then stored and modified in the catalog.

DBA:

set option public.brecks_option = 'default'

Paulley:

set option brecks_option = 'paulleys string'

DBA:

SELECT * FROM SYS.SYSOPTION where option = 'brecks_option'

user_id,option,setting
2,'brecks_option',default
102,'brecks_option',paulleys string

A further suggestion:

You might even use the InitString connection parameter to specify a statement that will be executed right after the connection is established.

That way, you could add a statement to set the user-defined database option or to insert into a particular table "automatically" - i.e. without having to change the application itself.

(A custom login procedure would work as well but could possibly have side effects on other applications.)

Obviously this approach would require that the added information is known at that time (or can be accessed from the database with the help of such a statement...

Here's a kludge which serves to demonstrate exactly what is needed: a way to dynamically set a value that will show up in subsequent calls to CONNECTION_PROPERTY and sa_conn_properties:

-- dbisql session 1

SET TEMPORARY OPTION connection_authentication = 'Hello, World!';

-- dbisql session 2

SELECT Number, Value FROM sa_conn_properties() WHERE PropName = 'connection_authentication';

Number,Value
2,Hello, World!
1,Company=Sybase;Application=DBTools;Signature=000fa55157edb8e14d818eb4fe3db41447146f1571g2a1b5949cab32c7760419117ca3ce88770fecfd7

(don't let the numbers confuse you... "dbisql session 1" has connection "Number" 2 in the result set)

The AppInfo connection property also includes the OSUser, this information should be accessible like the CON peroperty.

IMHO, besides a application-specific approach based on user-tables, the particular problem discussed here could be solved in a general fashion if there were enhanced user-defined database options that could be both

1. connection-specific (just like temporary options) and
2. permanently stored (just like non-temporary options).

Such options could then be read by other connections on a per-connection base.

However, AFAIK this combination does not exist today, and besides this particular case, I would not know of a use case...but that's just me:)