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

    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

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

Children
  • 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
    SUGGESTED

    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.