I have a site running 16bit OI 3.7.x

They are having problems with their largest table.

The table has 16million records with approx. 100bytes per record.

There are 7 indices on this table.

At least one index is corrupted. If they try to access anything use btree.extract the user just locks up.

I have been trying many things to repair this situation.

I have been attempting to upgrade them to 32bit for yrs explaining that they had a ticking time bomb given the amount of data, processing, brown outs etc.

I did get them up running UD 3.0.x yrs ago so we are good there.

They are now ripe for an upgrade understanding that there are many benefits.

I need to first resolve the index issue and have some questions.

1. If I upgrade them from 3.7 to 7.0 do I need to go in order?

I.e do a 4.x upgrade, then which ever OI release/patch came next

and so on so forth up to 7.0

2. Do I need remove all indexes from all tables and then upgrade and once at 7.0 then re-index all tables?

I am assuming I need to re-index as 7.x releases do not have the 32k limitaion.

Any help is greatly appreciated.

I think you have two options.

Option one is to upgrade version by version. You'll need to go from 3 to 4 to 7, stopping at intermediates along the way. You won't have to do them all, but you'll have to do the major ones and probably the last minor one.

Option two is to install a fresh OI 7.x and do an appbackup/apprestore.

All things being equal (which means license costs), I'd go for option 2.

You should rebuild the index that's corrupt, but otherwise, you shouldn't have to do anything to your files or programs.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Thanks for the reply.

Curious that I wouldn't have to rebuild indexes as I assume if I rebuilt a large table like that in 32bit then attached the ! table to 16bit it would work?

Also, how come you mentioned option one at all? Wouldn't option 2 negate 1 as there would be no reason or advantage that way?

Just asking.

Hi Bruce,

option 1 allows you to keep the number of SDP licenses…beyond 1.

Because the index structure is the same, there is not a problem. The index structure is identical from ARev 3.10 up through the most recent release of OpenInsight.

Option 2 doesn't negate option 1. You end up in a slightly different place. A new install will remove some of the items that are no longer shipped with the product, like REPORTER, ACCESS, 16 bit stuff, the easter eggs, and such. I'm also reasonably sure there is a difference in license cost.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Bruce,

Actually, Dave and Sprezzatura are both incorrect in one thing - if you are migrating your runtime users from 16-bit OI to 32-bit OI, no matter how you do it, there is a charge for the re-issuance of the runtime licenses. This policy has been in effect since the release of 32-bit OI.

I do agree with Sprezzatura that the cleanest way to upgrade them is a fresh install of 7.x.

I was actually addressing the Developer licenses, not the Runtime. Don't they remain between major versions?

So, if Bruce does a clean install of a 7.2, can he get the DLL upgraded to the same number of Developer licenses that were in his OI16?

Dave

Dave

]I was actually addressing the Developer licenses, not the Runtime. Don't they remain between major versions?

Yes, as they did in the move from 16-bit OI to 32-bit OI.

]So, if Bruce does a clean install of a 7.2, can he get the DLL upgraded to the same number of Developer licenses that were in his OI16?

The upgrades will not change the user count of his Developer licenses.

Cheers!

So, how do you start with a clean 7.21 install from a CD (which installs a 1-user Developer License) and get a return of your higher Developer License count from a OI 3.7 install?

I have a customer with exactly that problem.

I imagine you Email payment plus 16bit runtime engine (Oengine.exe) quoting your OIv7.x serial / version and Revsoft will return the Oengine.dll of desired version, coresponding User Count stamped with the (new) engine #.

Payment would most probably expedite the process.

Richard Bright

So if I indexed (rebuild) a large table in 7.x and then attached that to a 3.7 system there wouldn't be a problem with large nodes?

Does the indexing routine in 32bit not take advantage of larger strings or is it the same routines and therefore "chain" for items larger than 32k?

I am curious as still needing to rebuild a site that has a projected rebuild time of 50+ hours where as in 32 it would be significantly less time.

As far as we are aware, the systems are compatible. That does not mean the code has not been optimised to make for faster rebuilds, just that the resultant storage structures have not been altered.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the Works forum...