Large Dynamics database

(0) Share

Report

Posted on by Nancy Cohen

460

A client noticed that their Dynamics database is getting quite large - around 35 GB. The table WSExceptionLog appears to be the culprit. With almost 3 million rows.

TableName SchemaName RowCounts TotalSpaceKB UsedSpaceKB UnusedSpaceKB

WSExceptionLog dbo 2787687 35527424 35522536 4888

A new error is being added at one to two per second. Today is filled with this:

“Token StartElement in state EndRootElement would result in an invalid XML document. Make sure that the ConformanceLevel setting is set to ConformanceLevel.Fragment or ConformanceLevel.Auto if you want to write an XML fragment.”

Any ideas what can be causing all the errors?

*This post is locked for comments

I have the same question (0)

All responses (7)

Answers (1)

Verified answer

Derek Albaugh on at

Like (1)

Report

Hello Nancy,

The WSExceptionLog is tied to Web Services for Dynamics GP. Normally, this table is written to if their is an exception with Web Services and/or an application or integration that is running Web Services.

If you're using eConnect, that could potentially be writing these exceptions as well.

If you go onto the server that Web Services for Dynamics GP is installed onto and go into Administrative Tools, you'll see a Web Services Exceptions Console. If you go into this Console, most likely you'll see system or validation exceptions listed over the selected dates, that are also writing to this table.

**NOTE: You'll need to be a Security Admin for Web Services to access this Console.

Looking at our case history where we've seen this error in regards to Web Services and related applications, it could be as small as the currency info in a IV00105 table compared to the MC40200 all the way to too many maps being activated at one time causing a time out issue.

Hope this helps get you on the right path, but normally, you can clear out the WSExceptions, making a backup if you want to keep it for historical reasons.

Thanks,

Was this reply helpful? Yes No
Suggested answer

MG-16101311-0 26,225 on at

Like (1)

Report
Let me start by saying that a 35 GB database is actually quite small :)

This table is your Web Services Exception Log table and as you would suppose, it belongs to the Dynamics GP Web Services. You probably have an integration that is trying to tell you that you need to change the ConformanceLevel setting to ConformanceLevel.Fragment. Because this is a written integration (in C# or VB.NET) the developer needs to probably check Stack Overflow on how to change their code. Here's a good example: https://stackoverflow.com/questions/25460208/saving-xml-file-and-conformancelevel

In the meantime, you can stop the Dynamics GP Web Services services and run a truncate on the table:

use DYNAMICS; go truncate table WSExceptionLog;

Was this reply helpful? Yes No
Nancy Cohen 460 on at

Like (0)

Report

Thanks to both of you for your responses, we will truncate for now and I am going to get our engineers to confirm how we use eConnect. We are an ISV for manufacturing and have never seen this before so I don't know if it is us or something else the client may have implemented.

Was this reply helpful? Yes No
abutler1986 677 on at

Like (0)

Report

Hi,

Sorry to re-open an old case but recently we had a customer where there WSExeptionlog was over 600GB.. in the end we truncated it then we proceeded with upgrading there GP however, how do we stop this in the future from building up so big?

Was this reply helpful? Yes No
Lucas Miller on at

Like (0)

Report

That sort of depends on what kind of data is being recorded in this log. For instance, if your GP Web Services integration tries to create a Sales Order, but the Customer Number you're using doesn't exist it would write that exception to the table, even if your code is designed to respond to that exception by calling a CreateCustomer method. If you don't need the exception information for troubleshooting or auditing you could potentially setup a SQL job to clear everything older than 3 months or something along those lines. Otherwise you could look at how you're calling GP Web Services any why such a huge number of exceptions are occurring in order to prevent them from happening in the first place.

Was this reply helpful? Yes No
abutler1986 677 on at

Like (0)

Report

Thanks for the response Lucas, I have noticed that they had the compatibility level not set to Simple, I think it was on Full. If it was Simple will this stop the log from ever getting to a crazy size again if they did not set a SQL job to clear it etc..?

Was this reply helpful? Yes No
Lucas Miller on at

Like (0)

Report

If the database is set to Full recovery mode then yes, the transaction log would continue to grow until you perform a transaction log backup. The data file wouldn't necessarily be affected by this. Changing to Simple and running something like DBCC SHRINKDATABASE could help, but if your WSExceptionLog table is really that large you'll need to delete some data out of it before this process to really shrink the database.

Was this reply helpful? Yes No