Hello,
We have occasionally been getting an AOS crash on our batch server. AX service stops, upon restart another crash. A DB synch seamed to remedy the problem but we want to get down to the root of it so it does not occur again. Looks like it is crashing on the below SQL update statement to syslastvalue. Could two of the same user sessions try to update this table and thus crash it out? Any other ideas?
Event log:
Object Server 01: |
[Microsoft][SQL Native Client][SQL Server]Changed language setting to us_english. |
UPDATE SYSLASTVALUE SET VALUE=?,RECVERSION=? WHERE (((((((USERID=?) AND (RECORDTYPE=?)) AND (ELEMENTNAME=?)) AND (DESIGNNAME=?)) AND (ISKERNEL=?)) AND (COMPANY=?)) AND (RECVERSION=?)) |
session 1 (-AOS-)
|
*This post is locked for comments
Did anybody got to the core cause for this. We had the similar issue over the weekend and restarting the SQL Services fixed the problem. But keenly interested in knowing the root cause. Any relevant guidance would help.
Thank you.
Ah, on the server config util. Yes, this is checked off...
Via admin > setup > server configuration.
There is no such checkbox.
DAX 2009
first checkbox on server configuration settings 'allow clients to connect to printers on this server'
Hi Peter, thanks for the reply.
Well, our batch server crashed again last night. I checked batch classes and everything is set to run on and there are no strict client run methods. Where can I see the checkbox "use aos printers" on aos settings? We do have auto printing setup, for our batch invoicing at night but that has worked without errors for a long time now. I've read that drivers might be the issue but we have not updated the driver on the printer and again its worked in the past.
Also, we are using tracing to see if we can narrow down the problem. We can see the session id from the event viewer that is causing the crash but using the tracing tool really doesn't help. There are some long processes for example BatchRun class. This class does have client methods but it is out of the box unmodified so I would assume it is not the cause of the problem.
As far as screen output: we do have infolog calls in some custom batch jobs but this has been okay for months so I would assume that this would not be a cause. The infolog does save and we can view it after the job has complete.
Any other ideas from anyone?
Thanks in advance.
you should indeed check both. If using printed output check printersettings, be sure not to use screenoutput. Also check if checkbox 'use aos printers' on aos settings is checked.
Peter
Hello Peter,
Thanks for the reply. Yes, we have been monitoring batch jobs, we have a bunch that run at night. We are going to use a trace to help find out what batch jobs are running when it crashes.
As far as client processes: can I simply search for the string "client" (public client methods) in some of our custom classes that we use for batches? Or maybe check the run on property of the class?
These jobs run on a daily basis and we don't crash every night. It seems very odd that if we do have a client process running on the server, that we don't see more crashing...?
Thanks again.
Hi,
Take a look at the batch queue, especially the last running batch process before the crash occurred, we had a similar problem and it appeared that a client process was being called from within the batch server.
Regards,
Peter
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,134 Super User 2024 Season 2
Martin Dráb 229,928 Most Valuable Professional
nmaenpaa 101,156