Attribute Tag counts wrong after migration

I have recently migrated a site from to 5.80. All seems to have gone ok, there were a few issues with having to replace problog with another package.
I have today identified an issue with the migrating of Tags. All of the tags have imported and are still associated with the correct page item, but when the migration imported the tags it created duplicate entries in the atSelectOptions table, when you try to get a tag usage count for a particular tag it is reporting 1 when there are multiples. I have done some testing by adding new tags into the site and for these the usage count is correct. I have also tried adding an existing tag into another page but that results in another entry in atSelectOptions and a count of 1 showing up multiple times. This is the code I am using to display the list and count

<ul class="tms-tag-list blog tags">

$ak = CollectionAttributeKey::getByHandle('tags');
$akc = $ak->getController();
$pp = false;

$tagCounts = array();

$ttags = $akc->getOptionUsageArray($pp);

$tags = array();
foreach($ttags as $t) {
$tagCounts[] = $t->getSelectAttributeOptionUsageCount();
$tags[] = $t;

for ($i = 0; $i < $ttags->count(); $i++) {
$akct = $tags[$i];
$qs = $akc->field('atSelectOptionID') . '[]=' . $akct->getSelectAttributeOptionID();
echo '<li><a href="/ns/written-source-communications/written-source-communication-search-results/?'.$qs.'">'.$akct->getSelectAttributeOptionValue().'<span class="postCount">'.$akct->getSelectAttributeOptionUsageCount().'</span></a></li>';


I am open to either changing this code to correctly show the count or fixing the underlying data,


View Replies:
ConcreteOwl replied on at Permalink Reply
I would run this query on the database and then export the results

Then drop the existing atSelectOptions table and import the new table..
You could also rename the existing atSelectOptions table instead of dropping it, this would allow you to get back to where you started if things go wrong.
To be on the safe side I would also export the entire database first.
chawilaclef replied on at Permalink Reply
a UNIQUE sql field set may solve it but you should keep c5 db structure virgin.
FaganSystems replied on at Permalink Reply
I ended up changing the code that rendered the list to remove duplicates, this seems to have worked well and isn't causing much speed impact.