If you're on 4.0 you may want to start service packing up a few versions before you get to the 5.0 conversion. I'm pretty sure your database has to be at 4.11 for the 5.0 conversion to work, and there are a few prerequisites along the way, (4.1, 4.3, 4.6 and 4.11). If you're going to do all that in one shot read appendix J of the RES 4.0 installation RMF. There are registry keys you can create and set to skip the incremental database upgrades.
As far as the upgrade cost, it depends on your system. You'll need a RES 5 license, which I think is about 700. If you have an old parallel key your dealership will probably want to upgrade it to a USB instead of putting a parallel board into the new server. If you're using eclipse workstations they'll probably have to be replaced. They run on XP which is EOL, but also not compatible with RES 5. WS4's are on CE4 which is also going EOL soon. my rep tells me that they're officially supported, but that they sometimes run slow after upgrading. LX's and above are fine.
If you're on 4.0 you may want to start service packing up a few versions before you get to the 5.0 conversion. I'm pretty sure your database has to be at 4.11 for the 5.0 conversion to work, and there are a few prerequisites along the way, (4.1, 4.3, 4.6 and 4.11). If you're going to do all that in one shot read appendix J of the RES 4.0 installation RMF. There are registry keys you can create and set to skip the incremental database upgrades.
As far as the upgrade cost, it depends on your system. You'll need a RES 5 license, which I think is about 700. If you have an old parallel key your dealership will probably want to upgrade it to a USB instead of putting a parallel board into the new server. If you're using eclipse workstations they'll probably have to be replaced. They run on XP which is EOL, but also not compatible with RES 5. WS4's are on CE4 which is also going EOL soon. my rep tells me that they're officially supported, but that they sometimes run slow after upgrading. LX's and above are fine.
I just had a bunch of quotes come in for this exact thing. I'll leave the hardware part out but $1032 for the licence fee. $2,300 for the labour to upgrade and test the locations. Prices in CDN $. Will probably pay for the license and muck about with the upgrade myself.
That's pretty much my plan too. We've got 19 restaurants running RES 4.x on Win2003 so I've got and extra year, but the plan is to get one up and running solidly, take an image of the server and have Micros use it to build the rest of the rollout. Unfortunately 5 of those restaurants are using eclipses, so phase 1 is to get all 56 of them swapped out by April. It's going to be a fun year.
The main difficulty most people will run into during a Res5 upgrade is that the initial DB conversion from Sybase 9 to 11 will almost always fail. Unless you are SQL-savvy and can both locate the upgrade scripts and apply the necessary fixes to views, indexes, and sometimes tables, you will be stuck and have to roll back.
Also, 4.9 is the minimum required version to go directly to 5.0 or higher, so as pmegan said, start service packing up now...
Just curious why it the database upgrade always fails? Sounds like a poor upgrade migration path if this is the case. Does it fail when upgrading a blank database? Or just one with totals?
Thanks
From what I can tell, it has to do with minor accumlated errors in index and view definitions in prior releases. The further back (release-wise) your original database was created, the more likely the chance you will run into an error during the upgrade. The ones I am dealing with were originally created 10+ years ago, for reference.
The Sybase 9 to 11 upgrade (at least during the 5.0 upgrade, have not tested the 4.12 version) performs a "sanity check" by forcing a ton of manual re-builds of the views, indexes, and default table values - so if anything is out-of-whack, you have to correct it before the upgrade script will complete and allow your database to be usable. On average for databases I have converted so far, it is one to two unique errors per database - each of which have taken me between 15 minutes and a few hours to resolve. The issues I have seen most often are corrected by temporarily changing indexes to not require unique keys (note the table so you can clean it up afterwards) and by copying and pasting broken views from a new shell database or a successfully-upgraded one into the database you are upgrading.
At present, our local Micros office insists on upgrading a lab system with a copy of each database so the manual fixes can be documented ahead of time and applied in a timely fashion during the actual migration. Given all of the above, it's definitely a sound decision and saves hair-pulling at 3am.
If you don't want the upgrade to fail, make sure the new box is the same computer name and IP address.
Also, it is a very very very very good idea to clear totals, and rotate all the encryption keys (and get that rebuild out of it) before restoring to the new computer.
Unless you ABSOLUTELY have to keep your totals, clear them and do a rebuild. Save yourself the headache.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.