Anyone seen issues with SuiteQL's starting to time...
# suiteql
w
Anyone seen issues with SuiteQL's starting to time out?
watching following 1
e
Curious if you have any BUILTIN functions in your query.
w
That was the first thing I checked considering your recent issue. But no, no builtin's at all
👍 1
I just asked chatGPT to rewrite the query to using traditional joins instead of standard ones. ie
FROM table1, table2 WHERE table1.id = table2.t2val
instead of
Copy code
FROM
    table1
    JOIN table2 ON table1.id = table2.t2val
And it might solve it.
e
Interesting
w
The problem I was having is that the query timed out if I added non-foreign key columns to the SELECT for a specific table. If I only used the list/record-fields then it was fine.
a
umm doesn't the sql preprocessor just convert those two queries to the same thing when it runs against the db?
w
Something weird is going on... I've narrowed the issue down to a small subquery that is failing. I'm having issues troubleshooting as it is very inconsistent. Changing a comment makes it fail?? The only difference in the two below are the comments on third and fourth column This works:
Copy code
SELECT
M.id AS id
--,M.custrecord_eqtmt_matched_line_lineuniq AS uniquekey --This is not a foreign key field and does not work
,M.custrecord_eqtmt_matched_line_group AS group_id --This is a foreign key field and works
,M.custrecord_eqtmt_matched_line_transac AS transaction_id --This is a foreign key field and works
--,M.custrecord_eqtmt_matched_line_desc AS line_description --This is not a foreign key field
,G.custrecord_eqtmt_match_gr_des AS group_description
,G.custrecord_eqtmt_match_gr_deb_cre_diff AS gr_deb_cre_diff
,G.custrecord_eqtmt_match_gr_status AS line_status
,MAX(T.trandate) OVER (PARTITION BY M.custrecord_eqtmt_matched_line_group) AS maxTranDate
,MIN(T.trandate) OVER (PARTITION BY M.custrecord_eqtmt_matched_line_group) AS minTranDate
FROM
TRANSACTION T
JOIN transactionLine TL ON T.id = TL.transaction
JOIN customrecord_eqtmt_matched_line M ON M.custrecord_eqtmt_matched_line_id = TL.id AND M.custrecord_eqtmt_matched_line_transac = T.id
JOIN customrecord_eqtmt_matched_group G ON M.custrecord_eqtmt_matched_line_group = G.id
WHERE
TL.subsidiary = 359
AND G.custrecord_eqtmt_match_gr_status = 3
But this doesn't
Copy code
SELECT
M.id AS id
--,M.custrecord_eqtmt_matched_line_lineuniq AS uniquekey --This is not a foreign key field and does not work
,M.custrecord_eqtmt_matched_line_group AS group_id --I have to have this comment
,M.custrecord_eqtmt_matched_line_transac AS transaction_id --I have to have this comment
--,M.custrecord_eqtmt_matched_line_desc AS line_description --This is not a foreign key field
,G.custrecord_eqtmt_match_gr_des AS group_description
,G.custrecord_eqtmt_match_gr_deb_cre_diff AS gr_deb_cre_diff
,G.custrecord_eqtmt_match_gr_status AS line_status
,MAX(T.trandate) OVER (PARTITION BY M.custrecord_eqtmt_matched_line_group) AS maxTranDate
,MIN(T.trandate) OVER (PARTITION BY M.custrecord_eqtmt_matched_line_group) AS minTranDate
FROM
TRANSACTION T
JOIN transactionLine TL ON T.id = TL.transaction
JOIN customrecord_eqtmt_matched_line M ON M.custrecord_eqtmt_matched_line_id = TL.id AND M.custrecord_eqtmt_matched_line_transac = T.id
JOIN customrecord_eqtmt_matched_group G ON M.custrecord_eqtmt_matched_line_group = G.id
WHERE
TL.subsidiary = 359
AND G.custrecord_eqtmt_match_gr_status = 3
watching following 1
e
What error is thrown when it fails? Or does it time out?
w
I'm running it in the console and I get a "invalid response" in the SuiteScriptError. But I think the query times out. If I run the query in a suitelet it gives me "Invalid Search"
e
Are you able to try through ODBC?
s
I believe SuiteQL is a translation layer that converts the query to the underlying Oracle database. I'm guessing there's a bug in the translation layer dealing with some SQL keywords in the comments (e.g. FOREIGN KEY) Probably best is to preprocess the query to strip out the comments before executing it in SuiteQL Also, some SuiteQL GUI (e.g. Tim's
SuiteQL Query Tool
) may wrap the query for pagination, etc. Try another tool to see if you're getting the same result e.g.
NimbusQL Full Release