Using SQL, where can I find the current value of an ICM User Variable? I use these for many things including open hours in admin scripts and when special helpdesk messages are ative. I've been reading the database schema document and it's telling me to look in the t_Persistent_Variable table and yet it is blank.
This query could be helpful, depending on the size of your contact center. This can only be ran against the logger; the aw and hds databases do not hold data within the persistent variable table.
SELECT uv.ObjectType, pv.ValueInt, uv.VariableName, pv.ValueChar
FROM Persistent_Variable pv, User_Variable uvWHERE pv.UserVariableID = uv.UserVariableIDORDER BY uv.VariableName DESC
The other option you have is using rttest. You can log into your Call Router and run this via command prompt, as an example.
Also, I seem to remember there being an issue with 8.x systems where the necessary flag on the Logger is disabled with the install/upgrade. That registry flag on the logger is located at...
Please advice if above registry key should be set to 1 on both loggers. I am having a trouble where some of the user variables are missing from Side A logger which are visible in side B logger. How do I synchronize both sides. Our organization has recently upgraded my UCCE system from 8.0 to 10.0
I did have the same questions, but now I just found out that these registry changes (both for the Distributor and Loggers) will be activated immediately (at least for our 9.0 platform), no need for a restart.
From that moment every SET node configured and executed by a script containing these SET nodes, will store these values in the DB tables (no auto dump from router memory to these tables).
jpsweeney77 way to be! I know it's been a year and a half but I just got around to looking at your post. Works like a charm on 8 as well with not restart needed. Now I've got a CUIC report showing my helpdesk group the active oncall afterhours number in a dashboard view. Alas, they will probably never use it but man does this open up possibilities for me. Thanks.
Old post here but wanted to run past you all on this topic. I have Persistent_Variable reporting open and set up some CUIC dashboards reporting on particular call type variables etc. What I'm finding is that the Persistent_Variable table is taking a bit to update in sporadic fashion. i.e the variable tag changes, routing function from the routers memory is good, everything is working sound, but the table does not update the proper ValueChar. Sometimes its a few hours, sometimes a few minutes.Nothing aligned as if it was interval data. When it occurs I run an expr check of the variable against the router and its working like a charm. Its just the reporting side is just slugging along (down to the logger). Anyone else run into this?
It's been a long time, but I do remember seeing this before. I even think the old SRND mentioned that using persistent variable reporting caused extra load on the DB, which I always assumed meant that it would be a second class citizen and not updated with the same frequency as the other tables, but it was always eventually updated. I would open a TAC case and ask them if there's a magic reg key that could speed this up.
Aside from the TAC case, did you happen to try and see if this is happening on both Loggers, or just the one? Like for instance if you query the A side vs the B side, is it that both are always delayed and delayed by the same amount of time?
Yes sir, same deal on both sides. Tac finally got back to me and said its related to CSCwn98505. Which I did see in our RPL logs so checks out. I'm going to see if there is any potential to get a back coded fix for an ES prior to 15. We shall see!
