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.

Extremely Long SWQL query that works in SWQL Studio but not in EOC reports.

I have an SWQL query that takes 9+ minutes to run in SWQL studio, However when I try to move it to the report I keep getting invalid error.  My personal belief is there is a configuration timeout setting I need to adjust somewhere, or a size configuration in EOC, but I cannot seem to find it. I opened a case with support and they suggested I bring this up in the forum.

Is anyone running large SWQL reports that hit multiple sites and minimum 4 tables?  There is +- 6000 lines of SWQL including comments and ISNULL calculations.

If anyone has any idea where I can look to help solve this problem or Ideas I really would appreciate it. Right now, I am running them manually every day and moving them to a folder.

Thank you

Parents Reply Children
  • Case # 00474775 - EOC report Builder "Query Invalid"

  • Just in case anyone was following this. Eventually we changed more timing configurations to an hour and that solved the issue, to a point. Let me explain.

    1. The report never uploads into EOC via writing the code. However since we have a development environment that is much smaller we wrote the same reports, exported them. then imported them.  This solved the problem of the report building time out.  If we have to modify, its back to dev make the changes export and import.

    2. The reports will run on the web, but much slower so I would have to increase the time out even more.  Basically this was unacceptable from a performance and a customer service prospective, so at the moment we  manually run them in SWQL studio and put them into a csv and post to a shared folder. Not an ideal solution.

    3. Once we are fully staffed and trained up again, we will attempt to script this.

    Bottom line support gave us a work around, but that just pushed more manual labor to a different department.