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; } } }

Backingstore Format / Version?

Mongoose

Riddle me this .. .. .

Knowledgebase Article 55361 - https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=55361

states that you should update your backing store when you upgrade Teamsite.

So this implies that it is possible for your backing store format/version to get out of step with your teamsite version - and that at somepoint they *may* become incompatible!

So .. .. how can you tell what format / version a backing store is at?

Thanks
Andy

Find more posts tagged with

Comments

Adam Stoller

Riddle me this .. .. .

Knowledgebase Article 55361 - https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=55361

states that you should update your backing store when you upgrade Teamsite.

So this implies that it is possible for your backing store format/version to get out of step with your teamsite version - and that at somepoint they *may* become incompatible!

So .. .. how can you tell what format / version a backing store is at?

Thanks
Andy

You're misinterpreting the KB article.
If you take, for example, a 5.5.2 backing store and copy it to your 6.7.1 server and activate it there - TeamSite will "upgrade" the backing store such that it will be accepted by 6.7.1 and cannot be copied back to your 5.5.2 server. However, the simplistic upgrade that is performed by the server in such cases does not do a thorough job of converting the backing store - therefore, once you've copied the 552 store to the 671 server (as a secondary store) you should use iwmigrate to read from the simplistically converted copy of the 552 store and write it "correctly" into the new 671 store.

Mongoose

Maybe I am slightly confused - but that's what TeamSite does to me!

So the specific issue we have is that we have just upgrade to 6.5 from 6.1 - and Interwoven (quoting the attaching KB) are stating that we need to run iwmigrate. This will be a massive undertaking for us, and I don't see a specific reason to do so.

However, Interwoven support have stated that by not doing so "may cause corruption in your store" and we "will most definitely begin to experience performance issues" - and this is undocumented process in their upgrade procedures, I am slightly concerned!

But it does leads me to assume that a backing store converted from 6.1->6.5 is in someway inferior to a backing store installed directly at 6.5. So how can you tell what version a backing store is at - and when and under what circumstances should one use iwmigate to remedy this?

Thanks

sample data.txt

crosstab_Sample.rptdesign

pdasarat

As you think not to run iwmigrate on your new store bcos it's a time consuming process based on your store size. We had a same scenario as you have now, we had upgraded from 5.5 to 6.5 and as per IWOV recommendation we planned an iwmigrate. The estimated time required for entire store migration was more than a week (250 gigs). Since we didn't want to take so much time, we kept running 6.5 on 5.5 store. Sooner we ran into lots of issues, where the store goes down frequently.

Later we moved the store to another server, did an iwmigrate offline and then moved back the store.

Don't feel that running an iwmigrate is inferior than a fresh install.

I'm not sure if this answers your question, but at some point you have to migrate!!!

-Pradeep

Frederik

We also did a 5.5 to 6.5 upgrade (± Mar 2006), initially with just a binary-copy of the iwstore. We had issues (not all related to the 'old-format' iwstore, some were due to a disk crash). Out of precaution, and to avoid a potential future "we told you so" from Support, we iwmigrated the store (Jul 06)

Remember that you can run iwmigrate incrementally, so you can run a lot of it in the background... but yeah, it's a hassle, and you DO want to try it out in non-production first.

iwmigrate does lose a bit of information, like the original submit timings (I forgot what exactly, but some automatic metadata gets set to the time/situation of the iwmigrate, instead of the original), and some fileversions that aren't part of named editions (like if a file changed multiple times between making editions)...

I've ranted various times about this in the past on the forum, maybe even wrote sth useful too. Do a search Smiley Wink