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

SOLVED

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.

Thanks

Parents
  • 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.

    John

  • 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.

  • +1 in reply to mhainesalt
    verified answer

    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 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 rclowe

    I believe you must keep MAS_SYSTEM to be able to re-migrate ( this is an important database to have a SQL backup of)

Reply Children
No Data