Yea, the Deploy package doesn't transfer volatile data so it would have to be a manual process. I guess it's just transfering things in the right order to ensure keys exist. Hopefully the fact we use Guids should make that a little easier.
There's an issue if you've had Stores, Countries, Currencies or other things, that since has been deleted.
These things are transferred via Deploy, and so you can't import them, the import job will fail due to duplicate primary key error, so the existing items will have to be filtered out of the import job, which there isn't any option to do with the import task in SSMS.
I don't know if there is an easier way to do this, that I am missing, because curerntly, I cannot see any way forward to complete this migration without the loss of data.
As far as I'm aware, we should have code that cleans up when things are deleted, but if thinks aren't and they are forming part of the deploy, is that what's going on?
It's not the same issue, but I don't think I described it very well either, sorry for that. It hasn't anything to do with items that has been deleted, i misjudged that.
My issue is, when trying to import data from the old project to the new, I get a duplicate primary key error, as store, currencies, countries and so on, already exists as they have been created by Deploy.
Hmm, I'm not sure why it would do that though as if the countries exist etc it should just use them. I'm not sure why it would attempt to reimport them 🤔
Well why wouldn't it? The SQL Export/Import job exports and imports all records.
The issue is, there is no way to make it ignore it when items already exists, and then it throws the the error saying: Duplicate Primary Key Error, and stops.
If all tables were empty, or did not exist yet, it would not be an issue.
But because some items with the same primary keys already exist in destination tables, as they have been created during deployment, the import job fails, as there is no way to ignore these errors.
It should just skip these records. But I can't seem to find any option in SSMS to do that.
I don't know if there is any other way, to export/import the data, where there is an option to skip items that already exists in destination tables, and avoid the duplicate primary key error.
Or summarized:
What is the best way to move volatile data like orders and such, from one DB to aother after an upgrade/migration?
Can you disable the constraints in the DB and then perform the import of the orders etc (excluding setting entities like store, countries, etc) and then assume when you turn the constraints back on, those things should just exist?
I finally fixed it, by using the SQL Server Data Comparison tool in Visual Studio. 🥳
So for posterity, I'll try and describe what the issue was, in case someone else finds themselves in a similar bind.
When Vendr was installed for the first time on this project, a Store with countries, currencies and other settings was created.
I think we ran into some trouble, so we deleted everything, and created it again from scratch. However, when things are deleted in Vendr, there are still database entries, with relations to each other.
After migrating/upgrading Umbraco from v8 to v10 and upgrading Vendr from v2 to v3, we needed to move orders and other data, that had been changed in the database, since a backup had been made for the upgrade/migration.
The Import/Export Wizard does not skip records already in the destination tables, which causes the Duplicate Primary Key errors.
It also does not seem to handle Foreign Key constraints very good, meaning importing everything in the correct order.
Using the SQL Server Data Comparison tool in Visual Studio fixes that, as you can control what data to move, and it seems to handle foreign key constraints, and importing everything in the correct order.
Migrating Umbraco 8 to 10
After a successful upgrade/migration from Umbraco 8 to 10, I want to move data that is not transferred via Deploy, which could be
I figured I would use the Import task in SSMS, but I get foreign key constraint errors.
So my question is, how do I move this data from the old solution to the new?
Yea, the Deploy package doesn't transfer volatile data so it would have to be a manual process. I guess it's just transfering things in the right order to ensure keys exist. Hopefully the fact we use Guids should make that a little easier.
Ok, so any suggestions what the best order would be?
There's an issue if you've had Stores, Countries, Currencies or other things, that since has been deleted.
These things are transferred via Deploy, and so you can't import them, the import job will fail due to duplicate primary key error, so the existing items will have to be filtered out of the import job, which there isn't any option to do with the import task in SSMS.
I don't know if there is an easier way to do this, that I am missing, because curerntly, I cannot see any way forward to complete this migration without the loss of data.
Could this be linked to this issue? https://github.com/vendrhub/vendr-deploy/issues/18
As far as I'm aware, we should have code that cleans up when things are deleted, but if thinks aren't and they are forming part of the deploy, is that what's going on?
It's not the same issue, but I don't think I described it very well either, sorry for that. It hasn't anything to do with items that has been deleted, i misjudged that.
My issue is, when trying to import data from the old project to the new, I get a duplicate primary key error, as store, currencies, countries and so on, already exists as they have been created by Deploy.
Hmm, I'm not sure why it would do that though as if the countries exist etc it should just use them. I'm not sure why it would attempt to reimport them 🤔
Well why wouldn't it? The SQL Export/Import job exports and imports all records.
The issue is, there is no way to make it ignore it when items already exists, and then it throws the the error saying: Duplicate Primary Key Error, and stops.
If all tables were empty, or did not exist yet, it would not be an issue.
But because some items with the same primary keys already exist in destination tables, as they have been created during deployment, the import job fails, as there is no way to ignore these errors.
It should just skip these records. But I can't seem to find any option in SSMS to do that.
I don't know if there is any other way, to export/import the data, where there is an option to skip items that already exists in destination tables, and avoid the duplicate primary key error.
Or summarized: What is the best way to move volatile data like orders and such, from one DB to aother after an upgrade/migration?
Can you disable the constraints in the DB and then perform the import of the orders etc (excluding setting entities like store, countries, etc) and then assume when you turn the constraints back on, those things should just exist?
Wouldn't that just give duplicate values?
I finally fixed it, by using the SQL Server Data Comparison tool in Visual Studio. 🥳
So for posterity, I'll try and describe what the issue was, in case someone else finds themselves in a similar bind.
When Vendr was installed for the first time on this project, a Store with countries, currencies and other settings was created. I think we ran into some trouble, so we deleted everything, and created it again from scratch. However, when things are deleted in Vendr, there are still database entries, with relations to each other.
After migrating/upgrading Umbraco from v8 to v10 and upgrading Vendr from v2 to v3, we needed to move orders and other data, that had been changed in the database, since a backup had been made for the upgrade/migration.
The Import/Export Wizard does not skip records already in the destination tables, which causes the Duplicate Primary Key errors.
It also does not seem to handle Foreign Key constraints very good, meaning importing everything in the correct order.
Using the SQL Server Data Comparison tool in Visual Studio fixes that, as you can control what data to move, and it seems to handle foreign key constraints, and importing everything in the correct order.
Nice work on getting this working and thanks for sharing the solution that worked for you. Hopefully this might help others in the future 👍
is working on a reply...