Getting an error while upgrading GP2013 to GP 2015 R2 with the duSQLAccountSynch error DBMS 2601

(0) Share

Report

Posted on by Community Member

I am encountering an issue with the ASIEXP86 table when upgrading to Microsoft Dynamics GP 2015 R2:
"The stored procedure SynchronizeTableData() of form duSQLAccountSynch : 27Pass Through SQL returned the following results: DBMS: 2601, Microsoft Dynamics GP: 0."

*This post is locked for comments

I have the same question (0)

All responses (15)

Answers (1)

Verified answer

coquisalsa 2,725 on at

Like (3)

Report

Have you installed the latest GP 2015 R2 hotfix. You can download it from this link:

https://mbs.microsoft.com/customersource/northamerica/GP/downloads/service-packs/MDGP2015_PatchReleases

It is important that you only upgrade GP databases after installing the hotfix.

There are known issues with the GP 2015 R2 installer:

community.dynamics.com/.../162238

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks Jorge for your support. I installed the hotfix and everything run as execpted.

Was this reply helpful? Yes No
Althea ADS 10 on at

Like (0)

Report

I have this same error when trying to upgrade GP2015R2 to GP2018R2 and 18R2 was just released the other day so no later hot fixes, etc. This isn't fixed yet? Any idea what I need to do as this is a different version?

Was this reply helpful? Yes No
Suggested answer

Lucas Miller on at

Like (0)

Report

Althea,

This is something we're currently tracking as of yesterday afternoon. It seems similar to the issue that was previously found and addressed in GP 2015. We've documented this in the Known Issues blog post for the GP 2018 R2 upgrade:

https://community.dynamics.com/gp/b/dynamicsgp/archive/2018/09/07/microsoft-dynamics-gp-2018-r2-and-year-end-upgrade-known-upgrade-issues

You'll want to review that article for more information about the issue as well as the workaround.

We'll be writing this up for the Development team to review for a upcoming patch.

Let me know if you have any questions.

Was this reply helpful? Yes No
Rob Klaproth 1,730 on at

Like (0)

Report

Lucas Miller, I am really concerned about the quality of the releases today. We have seen these ASIEXP86 errors all the way back from GP 2015R2 and they still continue. Even with the latest 2015R2 hotfixes, when we upgrade clients from GP 2010 or GP 2013, we get the ASIEXP86 error and it's still not resolved.

I know this error is NOT related, but it's in the same table, so Microsoft really needs to take a thorough look. I would love to see them resolve the issue with the favorite display name on 2015R2 once and for all because 90% of all the client upgrades I do have an error on that table and it's been a known issue since GP 2015R2 and still not resolved, and now a new issue with 2018R2, so they need to take a good look at all the upgrade code for that table and make sure they account for the fact that customers actually DO rename the COLUMNS when they create a favorite, that's the entire purpose of having favorites is to let people rename the column display names.

Thank you,

Rob

Was this reply helpful? Yes No
Andy Seymour on at

Like (0)

Report

I just got this error upgrading to GP2018 R2 that was just released a week or so ago. When will there be a service pack as I will need to upgrade the Customer to an earlier version of GP 2018 to get round this problem and apply the Service Pack when released.

Was this reply helpful? Yes No
Lucas Miller on at

Like (0)

Report

@Rob Klaproth: Thanks for your feedback. To my knowledge this is the first time we've had a known issue with the ASIEXP86 since the previous issue in GP 2015 and that was resolved in 2015 R2. If you're still getting errors involving that table please do open support cases to let us troubleshoot and document the issue. Also, I asked around to see if anyone has had any upgrade cases where the cause was changing the Display Name of columns in a SmartList Favorite, but no one could recall such a situation. If you're seeing errors around that you should open a support case the next time it happens so we can investigate further.

@Andy Seymour: At this point the issue was first reported on Thursday evening and I tested and write it up for the Product Group on Friday. I imagine it will be addressed in the upcoming year-end patch for GP 2018. Also, you could work through removing any duplicates you're seeing and still successfully upgrade to GP 2018 R2. The blog article I linked above has the steps for you.

Let me know if you have any questions.

Was this reply helpful? Yes No
Rob Klaproth 1,730 on at

Like (0)

Report

Lucas Miller By deleting the rows in ASIEXP86 causing the primary key violation, will the user loose all their custom Smartlist favorites upon upgrade?

Was this reply helpful? Yes No
Lucas Miller on at

Like (0)

Report

Rob,

It's probably best to just explain what is going on during the upgrade of this table since it's different than some of the other modules:

1) First, a new table is created called ASIEXP86_T

2) The BULK INSERT command is run to populate ASIEXP86_T with all of the default column information for the default SmartList Favorites

3) Duplicate records (based on the PKASIEXP86 index) are deleted from the ASIEXP86

4) The default records from the ASIEXP86_T are inserted into ASIEXP86. This is where the error is happening, but it's on the AK2ASIEXP86 index rather than the Primary Key.

In my testing I only ever had it happen on the Employees SmartList when I added a new column to that, which adds a new record to the ASIEXP86. I couldn't repro with other SmartLists.

So, to answer you question in a roundabout way, no, deleting a duplicate from the ASIEXP86 table will not negatively change anything because that exact same record is being inserted back into the table by the above process. Also, the SmartList favorites themselves are actually stored in the ASIEXP81 table. The ASIEXP86 just holds the columns that are displayed on each of those favorites.

Was this reply helpful? Yes No
Rob Klaproth 1,730 on at

Like (0)

Report

Thanks Lucas, that does make more sense now. So, if I had deleted something from ASIEXP86 that happened to be part of someones actual columns in their favorites, would they just see the default column name? In another upgrade from 2010 to 2018 that I did (not R2), I deleted rows, and then when they ran their SmartList for some of the columns they got "Message 22786 Missing" instead of the name of the column. :) This was on the ASIEXP86 table it happens when you go on the hop from 2010 to 2015R2 (even with the latest service pack applied).

Here are a few others:

GP 2010 --> SP4 --> 2015R2 --> On the R2 hop with the latest service pack:

2010 SP4 Hop worked fine

2015R2: primary key violation

Had to run this against all dupes:

DELETE DYNAMICS..ASIEXP86

WHERE ASI_Favorite_Dict_ID = 0

AND ASI_Favorite_Type = 12

AND ASI_Favorite_Save_Level = 1

AND CMPANYID = 0

(below are the dupes I found)

0, 3, 1, 0

0, 9, 1, 0

0, 12, 1, 0

Here's another 2010 to 2015R2 upgrade (with latest SP):

"Conversion failed when converting the varchar value 'USD Credit' to data type int

(in this example upgrade I had to rename all the columns back to Debit or Credit, the client had renamed the default names Debit and Credit to USD Debit and USD Credit for some reason)

So, I've had a few upgrades, even after your 2015R2 hotfix that supposedly fixed the smartlist issue..

It seems on ALL Of them, the common denominator is that the user renamed some of the default columns.

Rob

Was this reply helpful? Yes No