Another blog post title for this one could be 'How to crash your AOS server in 1 easy step'. Because that is what we'll be doing in this post!
So be warned and take care if you wanna test the code on this blog. As always, it's your responsibility.
Anyway. We experienced some AOS crashes in our environment and started to investigate the cause. We could trace the crash to some specific code. When executed, we got following error in a dialog box on the client:
Internal error number 174 found in script
And with that, the AOS service died on us.
The application event log of the AOS server reported a 'Faulting application Ax32Serv.Exe' error, with event id 1000.
The code to simulate:
static void CrashAOS(Args _args)
{ SalesLine SalesLine;
SalesId SalesId='xyz';
;
update_recordset SalesLine
setting LineNum=-SalesLine.LineNum
where SalesLine.SalesId==SalesId;
return;
}
Looks like Ax didn't like what we tried to do with the update_recordset statement.
We ended up recoding, replacing the update_recordset statement with a select forupdate statement.
(Note: This code didn't give problems in old Ax versions, but it did in Ax 2009.)
Friday, February 19, 2010
Subscribe to:
Post Comments (Atom)
Has MS said anything about this error? I just caused it, and I wasn't doing any updating (but plenty of selecting).
ReplyDeleteNot much chance of MS giving feedback on such issues, as it's not standard code.
ReplyDeleteAfter all, if you know it's gonna crash, don't do it...
Same case caught me today. Your post did save me time on trying to figure out 'why'. Thanks! Maybe the same field can not be on both sides of the assignment in UpdateRecordset
ReplyDelete