TN - HIST - 26051802 Index error when migrating Historian to 2023 R2 SP1 P04
Last updated: May 18th, 2026Description
- Author: Dan Hojecki
- Published: May 18th, 2026
Details:
- Document Version: 001
- Applies to Version(s): 2023 R2 SP1 P04
Description
When upgrading Historian to 2023 R2 SP1 P04, you may encounter an error similar to the one below when you press Configure in the Configurator.
Microsoft OLE DB Driver for SQL Server
IDispatch error #3119
Warning! The maximum key length for a clustered index is 900 bytes. The index 'PK__#A6A86F4__097FF7C94097418F' has maximum length of 904 bytes. For some combination of large values, the insert/update operation will fail.
If you press Retry, an error similar to the below appears instead.
0x80040E2F
Microsoft OLE DB Driver for SQL Server
IDispatch error #3119
The MERGE statement conflicted with the FOREIGN KEY constraint "FK_TagExtendedProperty_TagExtendedPropertyName". The conflict occurred in database "Runtime", table "dbo.TagExtendedPropertyName", column 'PropertyNameKey'.
Solution Details
The root cause of this issue is a missing row in the Runtime database's TagExtendedPropertyName table. A fully populated table should contain the values shown here.
To add the missing row, run the SQL query below. Note that if you are missing a row other than ‘Dimension’ you will need to update the values accordingly.
USE Runtime
INSERT INTO TagExtendedPropertyName
(PropertyName, PropertyType, Facetable, Searchable, SubstringSearchable, IsEditable)
VALUES ('Dimension', 25, 0, 1, 1, 0)
______________________________________________________________________________________________
Give feedback about this article
Recommended articles
[ISS Support Case] Historian Migration Guidance
This machine will act as a flex license server for a couple HMI panels running Aveva Edge (2020) as well; those HMI Panels are also part of this upgrade project. The new Server2022 VM is built, and I have also created a dummy Server2022 VM on my laptop to experiment with as well. I have the System Platform Installation Guide manual, as well as a few other items, although I havent read every last bit of it. A couple quick questions Im running into at the start of the process on my dummy VM: Question: In terms of migrating the configuration of the old Historian to the new VM, I noticed that there is a configuration export tool that generates a text file on the legacy (WW Historian 2017) machine. I have also taken the step of creating a .bak backup of each WW Historian Database (Holding and Runtime) as well. Is it preferable to restore those databases into the new SQL Server Express? Or is it better to use the import tool when attempting to migrate to the new system?
Read More[ISS Support Case] Historian Migration How To 11.0 - 23.0
The old Historian is still in production. Basically, the client is running both App Server 2012 R2 and System Platform 2023 at the same time. Everything is replicated, both the hardware and software. The last step is to get the new Historian to read all the data from the old Historian so that the old Historian (and all the App Server 2012 R2 hardware and software) can be decommissioned. The new Historian does have a few more tags, than the old one, but we dont have to worry about them because I can run a query on those few tags before migrating the old historian data to the new historian. I tried shutting down the new Historian, deleting all the history blocks, copying the history blocks from the old historian, then restarting the Historian. This almost works, however, the data is spotty nulls occur in places in time they shouldnt, for example. Since just copying the history blocks from the old to new didn't work, I attempted the method shown here https://knowledge.insourcess.com/Operational_Efficiency/Historian/Implement_and_Support/Support_Tickets/Installation_and_Configuration/Installation_and_Configuration14/68223_-_Unable_to_see_data_in_imported_History_Blocks I made a backup of the Runtime and Holding database one the old Historian, copied them to the new Historian, and then attempted to restore them to the new Historian. I detached the Runtime database on the new Historian and selected Restore data base, then pointed to the Runtime data from old Historian. However, I received an error message that the Runtime database cant be restored because it is being used by the Runtime 11 database. See attached screenshot. What should my next steps be?
Read More[ISS Support Case] Historian Server Upgrade Questions
Almost ready to replace an old Wonderware 2014 Historian with a new Historian running System Platform 2020 R2 SP1 on a Windows 2019 VM. The new SP Historian server has been running for the past couple of months and collecting data. Would like to copy all history blocks from the 2014 Historian to the new Historian. Should I delete all history block folders on the new Historian and copy over all history block folders from the old Historian or do I only need to copy over the history block folders that do not currently exist on the new Historian? Need to make sure that we are keeping all of our historical data intact. Have been following https://3777554.extforms.netsuite.com/app/site/crm/externalcasepage.nl/compid.3777554/.f?formid=6&h=AACffht_vbqCKdcsKDfLP4IS_S5lgzIuuAQ&redirect_count=1&did_javascript_redirect=T as a guide. Also, have one Historian Enterprise 25K Tag license and one Historian Local 25K Tag license for a Backup Historian. After retirement of our old Historian and conversion to the new Historian, I will be standing up the Backup Local Historian. Since the Historian software will be exactly the same on the Backup Local History as on the primary Historian, will the Backup Local Historian know to use the available Historian Local 25K Tag license?
Read More