Kaseya Community

GetVariable() severely broken. Throwing internal errors when initializing an empty global variable (more wood for the fire)

  • We have code that has been working since we first started using VSA that is called by every other procedure (300+ scripts) to initialize global variables we depend on. When working on a new procedure I discovered that the same exact code we've been using all this time throws an internal error that I've never seen before 

    "FAILED to create IF step, Get Variable. Error = Invalid Parameter, script variable source name or data is missing (Line 10)"

    Further testing shows that if I copy the code line from the still working script into my test script it does work, as do all of the similar initializations in our core (line 3 below)

    The failure happens on the new code which is on line 7

    Currently, our core routines are still working, somehow being immune to this new behavior but if that should change ... massive domino effect and a rapidly sinking VSA that's dead in the water.

    We're on-prem so I have a SQL view that I can query every day to show me all of the failures, internal or otherwise since none of the internal failures trigger any form of alert or notification.  I'm more than happy to share that view and the query used to check for errors in fact I'd encourage all on-prem users to start checking for errors quite frankly because I'm tired of being told that "we're the only account something like this is happening to" and "Nobody else has reported this".

    If you don't want to go the SQL route, or you're on SAAS, start testing your code for issues like this, cmdresult & psresult failing to be initialized, nothing working on Server 2K19, and alarmsuspend() failing internally.

    Have a great Labor Day!

  • Make sure when you add the Step to the procedure you drag it in from the LHS and not add it by simply starting to type the command in

    I have seen when you start typing, the list of commands that appears is invalid in that the same command may appear twice or is just wrong, and selecting the wrong one will cause the procedure to fail

    So drag them in from the LHS

  • I've tested it with dragging the command form the left and dropping it, copying a group of getvariable()'s from a known good & working script and then editing it to make the value blank, and as noted copying a known working blank initialized getvariable() and dropping it in without making any changes.  The results are the same as noted.. the one that's copied, unchanged, works and the newly created one errors, no matter how it's created.

    copying an existing one, to create a new one inside of a long-established script allows you to create additional getvariable() statements with blank initialization within that script.  I tested this by accident when I was adding the new globals into the core.  I copied a block of three getvariable() statements that were blank initialized and pasted them a few lines down then changed the name of the global variables without causing any of the blank initialized getvariable() statements in that script to error.

  • It gets even better.. if you have code which contains valid functioning getvariable() statements that initialize the values as empty and then drag & drop a new getvariable() statement into the code to create a new blank initialized variable then the newly created statement will fail with the internal error while the rest remain valid and functioning.

    Looks like it may be issues with the script editor itself.

  • Can you not set the global variables in the system itself, instead of running a script to set them every time?

  • There's a difference between those variables, which are essentially constants, vs. variables that must be defined as global to pass values between procedures.

  • So .. some interesting developments here:

    The behavior as it is now corrects a 'feature' that our previous admin took advantage of and did not document.

    At one point the editor would init the fields for display and editing with a space which was not always removed.  This space is not displayed when viewing the code and the tests for empty values display as " " (with a space) for reading clarity.

    It get's even more convoluted when expanding variables because a variable that is initialized as "{space}," displays as "," and expands the same way, without the space, when used without being quoted and it's expanded as containing the space if used inside of single-quotes.