Error Number 0x80040e14 Description ALTER DATABASE failed because a lock could not be placed on database

This is a Go-Live upgrade, so obviously the test upgrade, and a subsequent "refresh migration" were able to go through.

However, now that we are trying the final migration, with just the MAS_XXX company data (no system files) we are getting this - over and over again:

We have severed all connections (the SPID workaround) and restarted the SQL Server several times.

Sage 100 Premium, going from 2019 to 2022.1 (LM 7103T has been applied). Tried to manually put the MAS_XXX.bak in the folder (per KB 111959). 

Anyone have any suggestions? We had hoped to get this done over the weekend.


  • 0

    Hey Cullen

    I've had a similar experience, gone through multiple KBs and attempted various solutions, just like you have. The only way I was able to go live was to start from scratch. Backup the entire MAS90 folder, especially all the MAS90\Reports and MAS_XXX\Reports folders, with all the converted forms, then uninstalled 2022 completely, deleted the MAS_System and other company databases. Once everything was cleaned up, I reinstalled and remigrated, converted data, then restored the reports folders and any module\custom folders. That was the only way I could move forward, painful as it was, I was able to have the client up and running for the Monday morning go live fun.

    Good luck.


  • 0 in reply to Johnbhoy

    Thanks John,

    It didn't quite come to that, and thank goodness this client's IT administrator is smart and stubborn and wouldn't let it go. After the 6th attempt I had given up and decided sleep was the best solution (and Sage City). He stuck with it a bit longer and, since the other company's MAS_XXX database had already migrated successfully we assumed the problem was that Sage was doing something strange with the other, much larger, MAS_XXX database. So he just removed the database completely and after that the "re-migration" finally went through successfully.

    I don't know if there is something Sage doesn't understand about MS SQL Databases, or if Microsoft is somehow making this deliberately difficult for Sage - but this process really should NOT be this difficult. 

    Here is what it says in KB # 111959:

    Option I:
    Contact Sage Support for Program fix for Sage 100 Premium 2020 - 2022 [Well, we has already applied the HotFix] 
    Option II:
    Upgrade to Sage 100 2022 [We are on 2022.1]
    Option III:
    1. Create a manual backup of the MAS_System database to the \INSTANCENAME\MASSQL\DATA folder
    through SQL Server Management Studio. [Tried that and several variations of that, except since we weren't migrating system files we were only concerned with one of the MAS_XXX databases]
    2. Run the migration tool as Administrator. [Every time]
    3. When prompted to overwrite the backup in the previously mentioned location, click Yes. [Yup]
    Option IV:
    1. Reinstall Sage 100 ERP 2021 base product. [Not sure if them mean 2022 base product, but I guess that would have next]
    2. Run migration tool as Administrator [Of course]
    3. Convert source data.
    4. Install product updates as needed.

    I guess we need to suggest an Option V:

    Remove the target database that blows up and re-migrate.

    Onward through the fog, as we used to say back in Austin, TX, back in the day Sunglasses

  • 0 in reply to rclowe

    How did you make out?  I have had situations where permissions were different on some databases, especially if they were previously moved to a different location than the other databases due to size constraints.  There is also some articles regarding whether the master database has any processes in Killed/rollback state that could affect things as well.

  • 0 in reply to mhainesalt

    Ended up deleting the target MAS_XXX database and the migration worked.

  • 0 in reply to rclowe

    Glad you got through it and didn't need to blow away everything and start over. Good luck with the go live today.

  • 0

    This has been an enormous problem for me recently as well.

    The issue in my case:  if a Premium to Premium migration fails, then it frequently ( always? ) leaves your new Sage 100 version in a state where you can't get in, and the primary advice from Sage is to reinstall Sage 100 completely.

    Reinstalling isn't a great solution since larger companies frequently have multiple enhancements that must be reinstalled.

    In my case, I keep getting all sorts of errors - some of which seemed to be operating system related. And like Cullen - I'm going through an initial migration and a test re-migration to try and rule out problems on go-live day. It sounds like this is a common issue.

    The only way I've found to combat this: 

    1. Completely backup \MAS90 and all subfolders

    2. Make a SQL backup of working MAS_SYSTEM and MAS_XXX databases

    3. Save these for use if the migration crashes and results in one of several errors in which Sage offers no recovery option and only suggests a total re-install

    I also try to clean up any prior MAS_xxx.BAK or MAS_SYSTEM.bak leftover from prior failed migrations

    This is hugely frustrating and I think in the future will be a reason why Premium customers might upgrade infrequently

  • 0 in reply to rclowe

    Deleting the MAS_XXX database prior to migration is one of the next things I'm going to try too

  • 0 in reply to Wayne Schulz

    For the target system, a backup of MAS90 and MAS_System is enough to reset after a failed migration attempt.  I have done that many times.

  • 0 in reply to Kevin M

    Thankfully that's what I had last night. So far, I haven't seen any specific pattern to the errors. Most of mine don't seem to be the same error, but they frequently deal with rights or file-in-use problems.

    To get back on my feet:

    I renamed the \MAS90\... to old.MAS90\..

    Copied back the backup copy of  \MAS90 (and all subfolders ) that I had saved

    Restored MAS_SYSTEM SQL backup

    Restarted migration 

    The first time I did not have a copy of \MAS90 or MAS_SYSTEM, and a complete reinstall wasn't the way I planned to spend my night

  • 0 in reply to Wayne Schulz

    I've been burned by that myself, and am now in the habit of taking a backup immediately after the initial software install (including enhancements and service config), so I can always reset to that point.

    If you've done a test migration, and made changes to system settings (Roles...), take a fresh backup before trying another migration.  I've had initial test migrations go fine, only to have 2nd migrations fail with various errors.