Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Micros upgrade from 4.7 to 5.4 1
- Thread starter JosueICR
- Start date
-
1
- #2
Are you getting a new server for Res5, or upgrading the OS on your existing server?
I just finished a rollout upgrade to 5.4 on systems running 4.7, 4.8 and 4.11, with new servers. I have two test computers, one with Res 4.11 and one with Res 5.4 and crystal reports. If you can do the same, it will make the upgrade process easier, and allow you to take a test run. Sometimes you'll have some data corruption if you leave your totals in place, and this is a good way to know about it ahead of time. Run your EOD reports for a couple of days and compare them against your live reports. Also, run all of your scripts and make sure they're working. Do the same if you have any custom tables or stored procedures.
The 2 things I encountered most were
[ol 1]
[li]Problems upgrading the database from 4.11 to 5.4. The recovery tool in DM is pretty sketchy, and if you start getting an error saying that the file can't be found, even though you know for a fact that it's there, things can get real messy, real fast. I've had it go so bad that I couldn't restore the original database back, and had to reinstall Res. This is the main reason I'm suggesting that you take a test run ahead of time.[/li]
[li]Reporting. The new reporter in Autosequences & Reports is horrible in my opinion. I've had tons of permission problems, and in the end made all of our store managers local admins, with full access to the Micros folder and inetpub\ It also helps sometimes to go to \micros\common\bin, open the properties for RptExpl.exe, and set "run as administrator" under the compatibility tab.[/li]
[/ol]
Here are the steps I used.
[ul]
[li]Upgrade the new server to Res 5.4 MR3.[/li]
[li]Make sure your test server is also running 5.4 MR3[/li]
[li]Open each custom report, click Database / Verify Database in the toolbar, and save the report. I'm not sure if this is 100% necessary, but the new Autosequences & Reports is really finicky, so I did this to play it safe.[/li]
[li]Open any .bat scripts that call dbisql with credentials and change the calling line from
dbisql -q <ScriptName>.sql
to
dbisql -q -nogui <ScriptName>.sql[/li]
[li]Open any .sql scripts with inline credentials and change the logon line from
connect username identified by password
to
connect using 'DSN=micros;UID=username;PWD=password[/li]
[li]Backup the Res 4.7 database, and restore it on the Res 4.11 computer using DM -U <path to backup>[/li]
[li]Change all encryption keys. (This is also not 100% necessary, but I had some encryption corruption issues with the first few, and that's something you really don't want on a live server. It's a miserable experience.)[/li]
[li]Back up the Res 4.11 database and restore it on the Res 5.4 server using DM -U <path to backup>[/li]
[li]When you're ready to go live, reboot all workstations through the control panel, and then disable the Micros NIC. When the new server is connected, the workstations will pick it up and re-CAL themselves, as long as you're using the same IP address.[/li]
[li]I don't like leaving pieces of previous versions behind, so the last, (not entirely necessary), is to wipe the flash on each workstation and run CAL. I've got some large systems, (the biggest is 22 workstations and 16 KDS screens), so this wasn't always possible in one shot. For locations like this, I did as many as I could on the day the new server went in, and then went back a day or two later to get the rest[/li]
[/ul]
Hope that helps.
I just finished a rollout upgrade to 5.4 on systems running 4.7, 4.8 and 4.11, with new servers. I have two test computers, one with Res 4.11 and one with Res 5.4 and crystal reports. If you can do the same, it will make the upgrade process easier, and allow you to take a test run. Sometimes you'll have some data corruption if you leave your totals in place, and this is a good way to know about it ahead of time. Run your EOD reports for a couple of days and compare them against your live reports. Also, run all of your scripts and make sure they're working. Do the same if you have any custom tables or stored procedures.
The 2 things I encountered most were
[ol 1]
[li]Problems upgrading the database from 4.11 to 5.4. The recovery tool in DM is pretty sketchy, and if you start getting an error saying that the file can't be found, even though you know for a fact that it's there, things can get real messy, real fast. I've had it go so bad that I couldn't restore the original database back, and had to reinstall Res. This is the main reason I'm suggesting that you take a test run ahead of time.[/li]
[li]Reporting. The new reporter in Autosequences & Reports is horrible in my opinion. I've had tons of permission problems, and in the end made all of our store managers local admins, with full access to the Micros folder and inetpub\ It also helps sometimes to go to \micros\common\bin, open the properties for RptExpl.exe, and set "run as administrator" under the compatibility tab.[/li]
[/ol]
Here are the steps I used.
[ul]
[li]Upgrade the new server to Res 5.4 MR3.[/li]
[li]Make sure your test server is also running 5.4 MR3[/li]
[li]Open each custom report, click Database / Verify Database in the toolbar, and save the report. I'm not sure if this is 100% necessary, but the new Autosequences & Reports is really finicky, so I did this to play it safe.[/li]
[li]Open any .bat scripts that call dbisql with credentials and change the calling line from
dbisql -q <ScriptName>.sql
to
dbisql -q -nogui <ScriptName>.sql[/li]
[li]Open any .sql scripts with inline credentials and change the logon line from
connect username identified by password
to
connect using 'DSN=micros;UID=username;PWD=password[/li]
[li]Backup the Res 4.7 database, and restore it on the Res 4.11 computer using DM -U <path to backup>[/li]
[li]Change all encryption keys. (This is also not 100% necessary, but I had some encryption corruption issues with the first few, and that's something you really don't want on a live server. It's a miserable experience.)[/li]
[li]Back up the Res 4.11 database and restore it on the Res 5.4 server using DM -U <path to backup>[/li]
[li]When you're ready to go live, reboot all workstations through the control panel, and then disable the Micros NIC. When the new server is connected, the workstations will pick it up and re-CAL themselves, as long as you're using the same IP address.[/li]
[li]I don't like leaving pieces of previous versions behind, so the last, (not entirely necessary), is to wipe the flash on each workstation and run CAL. I've got some large systems, (the biggest is 22 workstations and 16 KDS screens), so this wasn't always possible in one shot. For locations like this, I did as many as I could on the day the new server went in, and then went back a day or two later to get the rest[/li]
[/ul]
Hope that helps.
- Thread starter
- #3
- Status
Similar threads
- Locked
- Question