Finding what connection level variables have been defined

[justin_willey]

Is there a way of finding out what connection level variables are available in a connection - or am I missing something obvious? (In the circumstances I am working with variables may have been created by events or login procedures that I am not aware of - of course I can test for the existance of a particular variable with if varexists(), but I was after a list).

[Breck_Carter]

FWIW a connection-level variable created by an event is only visible to the event (and any code it calls), so it's not in the same ballpark as a login procedure.

[MarkCulp · Accepted solution]

AFAIK Currently there is no easy method to get a list of currently defined connection variables.

Of course the hard method would be to enumerate all possible names of variables and use varexists to see if each exists but that may take a very long time 🙂

[VolkerBarth · Accepted solution]

...the good part would be that during the check of the full namespace, at least one need not have to worry about connection-level variables being created or deleted in the interim - so the result would be deterministic and would not be affected by other connections:)

[justin_willey · Accepted solution]

Thanks Mark - I feared that would be the case. I'll just have to ask everyone who might add a mechanism that creates them to let me know. I think I'll have to pass on the alternative mechanism!!

[VolkerBarth · Accepted solution]

In case CREATE VARIABLE is logged in the transaction log (which I have not checked for), you might also be able to access that to analyse whether the current connection has executed such a statement. - That's a very cautious might: It seems like a real big hammer, would require according authority, and might not work (if at all) when logic is hidden within code...so I fear it might not be a solution:(

[VolkerBarth · Accepted solution]

So this would sound like a reasonable enhancement request, Mark?

[justin_willey · Accepted solution]

With around 1.15 x10^205 possibilities it's the "end of time arrives first" scenario that might outweigh the advantages 🙂 But then again it would get me out of cutting the grass / washing up etc for eternity, so .....

[VolkerBarth · Accepted solution]

Still you wouldn't have to sigh "Oh, I have to start from scratch again"🙂

[MarkCulp · Accepted solution]

CREATE VARIABLE is no logged in the transaction log.... since there is no permanent database change caused by the statement.

[MarkCulp · Accepted solution]

Possibly... but I'm wondering if Justin could just do a grep of the source periodically to determine if any new variables had been created?

[VolkerBarth · Accepted solution]

Thanks for the clarification - I had thought that a variable could influence query results that might influence DML statements (in case it is used to filter rows, say, for an INSERT SELECT). But obviously, the TL would not log the query itself but the resulting operations, and so the variable is not needed for a "replay"/restore.

Yes, I'm still learning basic stuff:)

[VolkerBarth · Accepted solution]

Yes - I bet just after he has finished the brute-force namespace query:)

[former_SQLA_member1694983 · Accepted solution]

Commenting in hope that after so many years someone has found a (better?) way of getting a result set with the connection variables.

[justin_willey]

Later update

I have discovered that you can see them if use use the debugger in Sybase Central, in the bottom left-hand window - if you switch to the Global view

[VolkerBarth]

Now you have to tell us: Did you find this after you

1. canceled or
2. finished

the mentioned "brute-force variable namespace query"?

[justin_willey]

Luckily I was able to sub-contract the job to some mice who operate in a parallel space-time continuum (dis-continuum??) who only wanted to be paid in cheese.