|
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). |
|
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 :-) 1
...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:)
(26 Jun '12, 16:17)
Volker Barth
Replies hidden
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!!
(26 Jun '12, 16:34)
Justin Willey
Replies hidden
1
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:(
(26 Jun '12, 16:42)
Volker Barth
Replies hidden
1
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 .....
(26 Jun '12, 17:03)
Justin Willey
1
Still you wouldn't have to sigh "Oh, I have to start from scratch again":)
(26 Jun '12, 17:06)
Volker Barth
1
CREATE VARIABLE is no logged in the transaction log.... since there is no permanent database change caused by the statement.
(27 Jun '12, 05:41)
Mark Culp
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?
(27 Jun '12, 05:42)
Mark Culp
1
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:)
(27 Jun '12, 05:46)
Volker Barth
Yes - I bet just after he has finished the brute-force namespace query:)
(27 Jun '12, 05:54)
Volker Barth
Commenting in hope that after so many years someone has found a (better?) way of getting a result set with the connection variables.
(29 Jan, 09:13)
adriancttnc
|
|
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
Now you have to tell us: Did you find this after you
the mentioned "brute-force variable namespace query"?
(27 Aug '12, 06:41)
Volker Barth
Replies hidden
1
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.
(28 Aug '12, 10:30)
Justin Willey
|
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.