Covert 1.67 DB to 5000 DB

[bluewhite4]

I was able to open the 4.X database on a 32-bit windows client, but the conversion to either 5.x or 6.x database fails with a .Net error.

Anyone seen this before?

[Tech Electronics]

Bluewhite4,

I think I should have mentioned one thing about the upgrade process. After each upgrade you need to run the DBTest utility on it to fix an issues that are fixable at that point. Also keep an eye out for Referential Integrity errors since that is a major source of DB corruption.

As for the issue with whether or not your machine is 64 bit that shouldn't make a difference, but then again I never ran the software on a 64 bit machine yet. The .NET issue I ran into before when I loaded software versions and then had to delete them to load previous versions, but that hasn't happened since they started unbundling the DB software from the SAaD software. It could mean that your version of .NET is not the correct one, try reloading the latest version of the SAaD application to see if it repairs it.

Thanks,

TE

[DND ON]

There should be no reason to do incremental back-ups from Axxess version 11.
 
I recently converted an Axxess version 10 directly to HX-5000 version 6, then loaded it with only minor clean up. No errors or issues popped up.

[Tech Electronics]

DND ON,

I have heard the same thing from other technicians, but I personally have had no luck with doing that so I stick with what I know works. Of course it is our policy to rekey databases instead of converting at this point, but you never know when that will change.

Thanks,

TE

[DND ON]

I've done two conversions and have two more to go. Rekeying systems on a 50+ node network isn't my idea of a good time!

[Tech Electronics]

DND ON,

It is not my idea of a good time either, but it does allow me to clean up an old database as well as understand how the customer is using their system so I can offer ideas on improving their call flows or processes. Also since there are new features in the 5000 that did not exist in some Axxess versions it would be a good idea to move over to those features instead of reusing work arounds. Then there is all the hidden flags and features through Online Monitor that do not always translate properly that can cause service issues later on.

Of course there is the counter that someone just converting a database will complete the job faster than someone rekeying it, but that is more of a vendor bottom line argument that assumes that any issues that arise will be minimal and easy to fix and fail into a different "service" budget versus the installation budget.

Thanks,

TE