Comments
-
Another simple 'complex' sort - Used for my alerting widgets.<br /><!--StartFragment --> <span class="s5">CASE</span><span class="s0"> </span><span class="s5">WHEN</span><span class="s0"> </span><span class="s11">ac</span><span class="s10">.</span><span class="s11">Severity</span><span class="s10">=</span><span…
-
Totally forgot to go over some complex sorting scenarios. My bad. Some complex sorting scenarios can indeed be simulated with revised table logic. This isn't always easy to achieve, though. I have some overview dashboards, for example, that combine lists of servers and sort them by a number of fields. The ORDER BY…
-
Thanks for the updates. Linear Charts: Most of these are working, but they are incredibly slow to load initially. A few did not work at all and of course those were the ones I used the most. Creating a new widget to load them did not resolve the issue, but oddly when I changed the perfstack then undid the change to allow…
-
Things to remember while you try to fix your modern widgets: * If you have to rename all the fields in use by a column, when you save the custom SWQL the column will vanish. You then have to recreate it, which may mean dragging columns around and dealing with the other bugs. * You can approach fixing tables one of 2 ways…
-
Here's a fun one that burned some serious time... If you have a column named [Group] then nothing you can do will ever get the table to work. I don't know how many different permutations I tried to get that column to populate when suddenly I decided to just rename the SWQL column to [GroupName] ... boom, worked fine. Out…
-
I just realized that there are new options in the overall table config ('Presentation') including search functions, refresh time, and... order by column. This works for simple cases, but unfortunately not all my desired default sorts are simple. Overall its a good update, but its been painful for me being the admin so far.
-
I should also add that my sorting (ORDER BY) statement seems to be totally ignored now. I haven't figured out any workaround for that little issue. There's a lot of nice new stuff in 2020.2.5 but I'm going to be busy fixing things I shouldn't have to fix for a long time before I can enjoy any of that.
-
Its the SPACES in the column names. Remove those and the errors will stop. Of course you then have to reconfigure the entire table to use the new names. This drove me crazy. I have to redo every table in my system now. Ugh! -christopher
-
After reading about that issue and pondering on it a short while, I added "ORDER BY Error" to your query above and now it works perfectly! Thank you! SELECT 'BGP Nodes' AS [Error], COUNT(NodeID) AS [Count] FROM ( SELECT DISTINCT ORN.NodeID FROM Orion.Routing.Neighbors AS ORN WHERE ORN.ProtocolID = 14 AND ORN.IsDeleted = 0…
-
SolarWinds has confirmed that this field is obsolete and no longer updated. The value is currently meaningless. Thanks everybody.
-
I'm still trying to figure out what that number means, mostly because I'm kinda stubborn. In the meantime, I've revised the display to count actual UnDP assignments against nodes (I don't have any running against interfaces). The numbers make sense now. Here's the updated SWQL query in case anybody's curious. SELECT…
-
Right - not what I need. I already have a nice custom query for this on the main routing view. I'm just looking for a small summary widget that I can place on the main NOC view to signify the need to investigate routing without cluttering the front page up.
-
That works perfectly in SWQL Studio, yet when I plug it into a Custom SWQL Query to display it on the website I get the dreaded "There was an error processing the request" error message... Any ideas why?
-
That query yields the number '240' which seems much more reasonable. This leaves me still wondering what exactly this number represents and why the primary poller has such a huge number while the additional poller shows 0. Either its not UNDP or my database is severely out of whack.
