nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Restore XML backup gives error: Could not import data in table 'AO_9412A1_AOREGISTRATION' column #1, value is too big for column which size limit is 65535,

Niels van Drimm

While doing a test migration from our Windows based/MSSQL2008 installation to a Linux/MySql installation, the XML restore (during the setup process) throws an error:

Import failed. Check your server logs for more information. com.atlassian.activeobjects.spi.ActiveObjectsImportExportException: There was an error during import/export with plugin Notifications and Tasks - Host Plugin(com.atlassian.mywork.mywork-confluence-host-plugin) #1.0.3:Could not import data in table 'AO_9412A1_AOREGISTRATION' column #1, value is too big for column which size limit is 65535, value is: {application:com.atlassian.mywork.providers.confluence,appId:,i18n:{:{com.atlassian.mywork.providers.confluence.blog.comment.aggregate:{0} comment on {1},com.atlassian.mywork.providers.confluence.action.comment.displayName:Comment,com.atlassian.mywork.providers.confluence.page.task.update.aggregate:{0} update to task on {1},com.atlassian.mywork.providers.confluence.page.edit.aggregatenew:{0} new edit on {1},com.atlassian.mywork.providers.confluence.blog.comment.aggregatenew:{0} new comment on {1},com.atlassian.mywork.providers.confluence.comment.mentions.user.title:{user} mentioned you in {title},com.atlassian.mywork.providers.confluence.comment.like.aggregatenews:{0} new likes of {1},com.atlassian.mywork.providers.confluence.blog.mentions.user.aggregate:{0} mention in {1},com.atlassian.mywork.providers.confluence.blog.comment.aggregates:{0} comments on {1},com.atlassian.mywork.providers.confluence.blog.task.update.aggregates:{0} updates to tasks on {1},com.atlassian.mywork.providers.confluence.blog.mentions.user.older:{0} older mention on this page,com.atlassian.mywork.providers.confluence.blog.share.aggregatenew:{0} new share of {1},com.atlassian.mywork.providers.confluence.page.task.update.aggregates:{0} updates to tasks on

Accepted answers

RianA

Hey guys,

It has been raised as a bug. For more information please refer to the following bug report.
* https://jira.atlassian.com/browse/CONF-27513

Feel free to check on the description, and please do comment and add yourself as a watcher for future update.

All comments

CharlesH1

Hi Niels,

Some basic things to check which may help:

The version of Confluence is the same on both instances? A minor difference should be okay ( e.g. 4.2.1 to 4.2.2) but not anything more significant than that.
Is your database encoding the same on both instances? e.g. UTF8
Have you got the same plugins on both instances?

Regards,

Charles

Niels van Drimm

Working with Atlassian support on this issue.

Atlasian strongly advices against using the XML backup and restore mechanism. So I'm in the middle of trying to migrate using database tools. While I got it work, one issue remains:

The SQL Server based database schema differs from a MySQL based schema. When you do a migration with database tools you end up with a MySQL schema which follows the original SQL Server schema.

Question is: does Atlassian supports a MySQL schema which is different than one created by the Confluence installer? Because I can imagine this could issues in the future while upgrading to newer versions.

Niels

unknown

Your data is too big for the column, thats easy to see. This happens a lot when developer expectations of use are exceeded by users. I have found that AO will not make schema changes, even if lossless (ie field declared as bigger in later releases of the plugin), the solution to this is to simply make the database type TEXT, which translates to unlimited. AO will not I think complain, or try to make any schema changes to revert, and the problem seen will go away. I've done this a bunch of times...

Probably should backup your database first just to be safe.

Niels van Drimm

Hi Andy,

Not sure if I read you correctly. You mean changing the data type to TEXT on the source SQL Server schema, or on the receiving MySQL schema?

Thanks!

Niels

unknown

Your receiving schema has the problem, you'll find a table of the given name, locate the column within it and update its type to allow 'more' data. When I ran into this I created some scripts, see this link.

Niels van Drimm

I tried. But the change I made to the schema is reverted when I restore the XML based backup. Interesting enough the plugin is Confluence system plugin.

Michael Regelin

I read with lot of interets this post.

We are going to import 5 huges spaces from Twiki to Confluence (between 400Mb and 1Gb).

The UWC importe gives me some xml.zip files wich i then import in confluence (copying to the restore folder and after restore from admin panel).

Is there another way "cleaner" to import the xml.zip file generated by the uwc ?

thanks if someone has advice on this .

sincerly,

Michael

RianA

Hey guys,

It has been raised as a bug. For more information please refer to the following bug report.
* https://jira.atlassian.com/browse/CONF-27513

Feel free to check on the description, and please do comment and add yourself as a watcher for future update.

Niels van Drimm

Hi Michael,

My suggestion would be to contact Atlassian supoort on your issue, or create a new question. Your question is a bit of topic in here.

Regards

Niels

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

restore

backup

xml