Hi all,
During a NAV2015 Data Upgrade, one of the steps is to update any fields linked to the "User Setup" table with Domain\Userid instead of just Userid. I received an error message that a field in one of our custom tables was too short. This field was overlooked when I updated all the userid-related fields to the new-standard length of 50.
I went ahead and changed the length of the field in the table, but I could not synchronize the data because NAV thinks that the table is locked by another process. I've stopped the service tier, but SP_WHO in SQL Management Studio still shows several SQL processes with the database open. And I can't restart the Data Upgrade until a synchronize data step on my custom table is completed (Data Upgrade reports an error when I start, saying a synchronize data step is required - which makes sense.)
I know from a prior test that if I stop SQL Server and restart, the database will have to go through a recovery, which will take about 4 hours - something I would prefer not to do.
Has anyone encountered this problem? Has anyone tried just killing the SQL process SPID's that appear to have the database locked? And if so, any negative impacts on the data recovery process?
Thanks
Ron
During a NAV2015 Data Upgrade, one of the steps is to update any fields linked to the "User Setup" table with Domain\Userid instead of just Userid. I received an error message that a field in one of our custom tables was too short. This field was overlooked when I updated all the userid-related fields to the new-standard length of 50.
I went ahead and changed the length of the field in the table, but I could not synchronize the data because NAV thinks that the table is locked by another process. I've stopped the service tier, but SP_WHO in SQL Management Studio still shows several SQL processes with the database open. And I can't restart the Data Upgrade until a synchronize data step on my custom table is completed (Data Upgrade reports an error when I start, saying a synchronize data step is required - which makes sense.)
I know from a prior test that if I stop SQL Server and restart, the database will have to go through a recovery, which will take about 4 hours - something I would prefer not to do.
Has anyone encountered this problem? Has anyone tried just killing the SQL process SPID's that appear to have the database locked? And if so, any negative impacts on the data recovery process?
Thanks
Ron