web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Finance | Project Operations, Human Resources, ...
Suggested Answer

GP 2015 to GP 2016 Upgrade fails on ASIEXP86 table

(0) ShareShare
ReportReport
Posted on by 75,854 Moderator

Knowing how much fun it is dealing with issues with the ASIEXP81 table during upgrades I thought I would be proactive with another upgrade I am doing. What exactly is this telling me and why does it make the upgrade fail?  There are 2,095 records in the ASIEXP86 table and this query return 27 records.

SELECT * FROM DYNAMICS..ASIEXP86
WHERE ASI_Field_Number NOT IN (SELECT ASI_Field_Number FROM DYNAMICS..ASITAB20)

I am doing the first hop of a GP 2015 to GP upgrade so this is GP 2015 to GP 2016. I can let the upgrade fail and look for duplicates but that is not what this script does. In this case can I simply delete the records where there is no match?

Categories:
  • Derek Albaugh Profile Picture
    Microsoft Employee on at

    When the ASIEXP86 table fails the upgrade, what exactly is the dexsql.log showing?

    I ask because there are a couple of different errors we'll see with ASIEXP86 and the duplicates issue we've published is just one of them.......

  • Richard Wheeler Profile Picture
    75,854 Moderator on at

    Derek, this was the same upgrade that failed last month. In this case I ran:

    DELETE DYNAMICS..ASIEXP86

    WHERE ASI_Field_Number NOT IN (SELECT ASI_Field_Number FROM DYNAMICS..ASITAB20)

    Before running the upgrade and the upgrade proceeds normally. I did examine the DU0000020 table and there is a GP 10 product for Smartlist builder back when SLB used to be part of GP. That would explain the custom Smartlist I see.

    I imagine in this case it removed the SL where the ASI_Field_Number no longer exists.

  • Suggested answer
    Derek Albaugh Profile Picture
    Microsoft Employee on at

    Ok, thanks for the update.

  • Richard Wheeler Profile Picture
    75,854 Moderator on at

    This is very odd. After loading the database I went into GP as 'sa' and ran several Smartlists. I logged out and had users log in and now everyone, including 'sa' gets this.

    pastedimage1588359711193v1.png

  • Derek Albaugh Profile Picture
    Microsoft Employee on at

    The images are hard to read, but it appears it is referencing the ADH_UserList_MSTR table which should be the ADH00100 table.

    It's not a table that gets setup per acct framework, but does get a new column added to it. I'd go into SQL Maintenance, for the DYNAMICS system database / Smartlist product, select this table if not all, then mark the options to drop and re-create procedures and run that.

    My thoughts are that the table got a new column added, but procedures didn't get updated to reflect that, thus the error.

    If the error persists, it may be the table structure that is incorrect.

  • Richard Wheeler Profile Picture
    75,854 Moderator on at

    Derek, in the DU0000020 table there is a reference to Smartlist Builder for GP 10. That was probably when this custom Smartlist was created. SLB was never upgraded but this SL is constantly used. They are currently on GP 2015. Is the any way I can export this one SL, remove all the current SLs and reinstall the SLs and then import this custom SL? Either that or fix this current problem without blowing everything away.

  • Richard Wheeler Profile Picture
    75,854 Moderator on at

    Derek, looks like you have done it again. Recreating those stored procedures appears to have done the trick. Now this is two upgrades for these folks where the same issues occurs. Could there be something in their DYNAMICS database causing this?

  • Derek Albaugh Profile Picture
    Microsoft Employee on at

    ADH00100 is a relatively new table, I think it got added when we introduced Workflow 2.0, probably GP 2013 R2, then it gets updated at probably GP 2016 to have the new columns, that should be about it.

    The only suggestion I guess I'd mention would be to make sure the DU000030 table is completely empty before starting any upgrade, whether major version upgrade such as GP 2015 to GP 2016, or just a service pack/hotfix update.

    Thanks

  • Richard Wheeler Profile Picture
    75,854 Moderator on at

    Good reminder. I just checked the DU0000030 table after the upgrade and there are 240 records sitting in there scattered amongst their 4 companies.

  • Derek Albaugh Profile Picture
    Microsoft Employee on at

    Yeah, old records in the DU000030 table can cause weird things to happen during an upgrade of Dynamics GP.......I've seen an upgrade fail on 15-20 tables, restore everything back and truncate DU000030 and the upgrade went through without any issues at all.........

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Winners!

Congratulations to our community stars!

Women in Power Builds Momentum

Expanding mentorship, skilling, and AI innovation

Congratulations to the August Top 10 Community Leaders

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Martin Dráb Profile Picture

Martin Dráb 582 Most Valuable Professional

#2
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 410 Super User 2026 Season 2

#3
CU-1234529-002 Profile Picture

CU-1234529-002 185

Last 30 days Overall leaderboard

Product updates

Dynamics 365 release plans