• State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 20 subscribers
  • Views 1134 views
  • Users 0 members are here
Options
Related
This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

MACRO SQL ERROR when alert action repeats but not originally

chucksimalchik

I've got an issue where I have an alert sending a POST to a third party system for volume issues to create incidents, but I've had to do some SQL to escape the backslash in the volume name. It works fine when the alert triggers initially, but if I set it to repeat in 1 day if it is still active, the same statement throws a MACRO SQL ERROR.

Ideally we want to resend the POST in a day, to ensure that someone hasn't closed the alert in the other system but not resolved the actual problem. The retrigger will reopen the case but if the case is still open, the duplicate will be suppressed. This is preventing that behavior from being enabled.

Any thoughts on how to resolve this?

Statement in alert action configuration:

"description": " ${SQL: SELECT replace(Caption, '\', '\\') FROM Volumes WHERE VolumeID = ${VolumeID}} Percent ${N=SwisEntity;M=VolumePercentUsed} used"

Output when alert initially triggers:

"description": " H:\\ Label:New H Drive f4b7ee73 Percent 96 % used"

Output when alert triggers after 1 day:

"description": " MACRO SQL ERROR - Incorrect syntax near '{'. Percent 96 % used"

Parents
  • +1

    ${VolumeID} is a very old variable name and directly accessing variables this was has been deprecated.  All the new ones are in the format of ${N=;M=} (As you see in the Percent Used language).  It's also dependent on the alert type ("Alert on...").  That's why it's best to grab this from the Variable Picker and re-use it from there.

    I'm assuming you are packaging this up as a JSON to send this via HTTP to another system - is that correct?

  • 0 in reply to KMSigma.SWI

    Good catch. This was a carryover from a very old alert and we didn't update this one, and it was staring me right in the face. Seems strange that the original isn't impacted but the repeat is, but software does what software does.

    I'm testing it to be sure the original and repeat will work as expected now and will confirm in a day or so.

    And yes, this is packaging JSON to post to another system for incident generation. For volumes we found we needed to escape the backslash character when posting, and this was the most efficient method to do so.

Reply
  • 0 in reply to KMSigma.SWI

    Good catch. This was a carryover from a very old alert and we didn't update this one, and it was staring me right in the face. Seems strange that the original isn't impacted but the repeat is, but software does what software does.

    I'm testing it to be sure the original and repeat will work as expected now and will confirm in a day or so.

    And yes, this is packaging JSON to post to another system for incident generation. For volumes we found we needed to escape the backslash character when posting, and this was the most efficient method to do so.

Children

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.