Working with GP2013, I encountered this error logging in: "An error occurred while loading or initializing an addin. Ask your administrator to check the Windows event log for more details. Dynamics will now close." Checking the Event Viewer provided a bit more information: "Microsoft Dexterity error: The description for Event ID 0 from source Microsoft Dexterity cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: An exception occurred while trying to load or initialize the addin located at VAT100ElectronicSubmission. Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'VAT100ElectronicSubmission, Version=126.96.36.199, Culture=neutral, PublicKeyToken=5eca28f6788f0a91' or one of its dependencies. The system cannot find [...]
The Insight application installed without any issues. However, the ScribeInternal database could not be created after several attempts. We tried creating the database manually, assigning the sa user to the db_owner role, and then updating the existing db using the internaldb.exe. Browsing the server, we noticed the SQL Server master database were owned by a 'not sa' user. Running the sp_changedbowner procedure only returned an error, and even Microsoft support was at a loss to explain how this had happened or how to change it. We installed a new SQL instance on the same server and verified sa was the owner of all the master databases. On this instance, we were able to create the ScribeInternal database successfully.
The problem report was built with a row set listing the full range of main accounts (+Main = [????], for ease of maintenance), and a column set which included DESC and ACCT columns. Drilling down on the main report page for the account list displayed the account string and correct period amounts, but some of the account descriptions were missing. The same report run for the prior month displayed all of the account descriptions. Drilling down on various individual accounts revealed that those not showing descriptions each had only unposted transactions in the current month (for comparison, accounts with both posted and unposted transactions had their descriptions displayed) When the open batches were posted, the report displayed all of the account descriptions.
One of our clients called for assistance with a receivables batch which refused to post. GP did not return any error messages, and the user had sufficient permissions to post this batch. The DYNSA user was able to post this batch in the test company, but not in the live company. When posting was attempted GP briefly displayed the posting status window and returned to the batch entry window without making any changes. No errors were found in the dex_sql log or a SQL trace.... but there was a lock on the PM10000 table held by another user. Once this user logged out of GP, the DEX_LOCK table cleared and the batch posted successfully. You can use the following SQL command to view the list of active GP users, and any locks held at the time you run this query: SELECT A.USERID , A.CMPNYNAM , A.SQLSESID , L.session_id , L.row_id [...]