When attempting to copy an element, Sharegate displays one of the following error messages:
- The content database has run out of free space.
- There was an error while uploading the file. This is likely due to an issue with the content database, such as running out of space.
- An error occurred between SharePoint and its database: 'Error details'
- An error occurred while updating the file. This may happen if the file was deleted, or if there is an issue with the content database, such as running out of space.
|Any error code ending with: -041 or -042|
This error occurs because there is a problem with the SharePoint content database, which prevents Sharegate from copying. In most cases, the problem is simply that the database has run out of free space. In other cases, this problem can occur when the database server is handling too many requests.
Verify the following elements (if you do not have access to the SharePoint server, contact your SharePoint administrator and ask them to verify this):
- Make sure there is enough free space on the destination SharePoint content database server.
If there is enough free space for the content database:
- Reduce the performance options in Sharegate to limit the amount of requests that Sharegate sends.
- Consult the SharePoint ULS logs to get more details about the error. It should contain details about an SQL error or a communication error with the database.
Special case for the error "System.Data.SqlClient.SqlException (0x80131904): Parameter '@someColumn' was supplied multiple times."
If you find this error message in the ULS logs, then it means that the issue is with the definition of the list's columns (the XML schema). More specifically, it means that the way the columns are defined in the list causes a value to be supplied twice to the database when an update is performed, which then causes the database to throw an error. The solution for this depends on which column causes the error.
If the column is a generic value like '@nvarchar1'
This means that your list's XML schema was probably customized by a developer and that the "ColName" property was set to the same value for more than one column. The best practice is to let SharePoint automatically assign the "ColName" property, so the best way to solve the situation would be to ask the developer who modified the list to remove the "ColName" values from the list's XML schema.
If the column is '@tp_Editor'
This means that the "Modified By" column is corrupted, either in the site collection or only in the list. If the issue happens with only one list, then the column is only corrupted in this list. If the issue happens in all the lists created within a site collection (even in new ones that you create), then the site column is corrupted, as well as the column in all the lists. This can be fixed by running one of the following PowerShell scripts to update the columns and correct them:
DISCLAIMER: Always perform a full backup of your SharePoint farm before running any of these scripts.
If the whole site collection is corrupted, use this script fixSiteCollectionModifiedBy.ps1 (modify the address of the site before running it)
If only a list is corrupted, use this script fixListModifiedBy.ps1 (modify the address of the site and the title of the list before running it)