Ugly Error on Micros Res 5.2

[pmegan]

I'm trying to restore/upgrade a database from one of our restaurants, (Res 4.11), on a Res 5.2 test server. Everything seemed to work, but when I tried to open the POS Configurator I got this error:

Database Error: Unknown user name or password.
[Sybase][ODBC Driver][SQL Anywhere] Invalid user ID or password
Alias: micros

Now to me that looks like there's something wrong with the micros user account. Either it doesn't recognize the micros database user/password, or there's some kind of mismatch between the micros user in the database and the encrypted user info keys in the registry. Now I can't even restore the database backup I took just before starting all this. The DB won't start so I can't open Database Manager, and can't even use DM -U from a command line; it gives me a "can not find key file" error and tanks.

Has anybody seen this before, and is there a way to get even the original db restored?

 

[DJensen999]

I had that happen once before, but it was on an EM server. Verifying/fixing a combination of the ODBC "Micros" data source and SQLResServerName service resolved the issue.

If that doesn't work, you should be able to uninstall Res, nuke the prepatchrestore files, then re-install 5.0 to allow the shell DB import and upgrade to 5.2 again.

 

[Moregelen]

Can you even get the SQL server to start? I've seen that error a lot when upgrading, and if you can still get the SQL server to start and get in through DBISQL you can fix it..

 

[pmegan]

Nope, SQL doesn't start. Even if I go into services and try to start it, all I get is that helpful "service started and then stopped" message.

How do you fix it through DBISQL? When I first restored the DB it would start in the control panel, this mess all started after that, when I tried to open Micros applications.

 

[Moregelen]

Well, first question.. does the box your restored it to have the same computer name and IP address as the one you pulled the database from? Because that is the main cause I've seen when going 4 to 5; RES 5 throws a shit fit when the IP address isn't the same, so I generally pop into dbisql right afterward and correct everything.

 

[pmegan]

The IP is the same, different computer name though.

 

[Moregelen]

That will do it too. I have no idea why from 4 to 5 it causes Micros to freak out, but it does. I always match the computer name and IP address right after a restore, and then reboot. If I don't, I get that error and the database won't start.

 

[pmegan]

Ok, so now that I have a server with a database that won't start, is there any way to get it going short of blowing everything out and reloading RES? I can't even restore the backup that I made to be safe, lol.

 

[Moregelen]

I know you said you can't even get dm -u running anymore, but if you still have a RES 4 database does a

dm -u "path_to_mbz.mbz"

Execute? Sometimes I just have to shove a RES 4 database into it log enough to get in and fix things, because even a dm -s won't work.

 

[pmegan]

Nope. This is what I get.

4/10/2014 3:51:59 PM Converting database: D:\DCP\Micros_2014_03_28_10_32.mbz4g2
4/10/2014 3:52:14 PM Restoring Micros backup file D:\DCP\Micros_2014_03_28_10_32.mbz4g2
4/10/2014 3:52:14 PM Decompressing backup file. 
4/10/2014 3:52:20 PM Restoring passwords and encryption keys.
4/10/2014 3:52:25 PM Restoring passwords and encryption keys failed, key file not found.

 

[Moregelen]

Ah. One of our branch offices ran into this. He hit his head on that for about 2 hours before just re-imaging the entire drive. Sorry, I have nothing on that error

 

[DJensen999]

Odd, shouldn't a backup import from 4.11 be an MBZ file? mbz4g2 would be 4.12.

 

[pmegan]

Yep. I tried restoring the 4.11 db backup to my 4.12 image to see if it would fail there, which it didn't. I was able to restore it onto the 4.12 system and open the Micros apps so I made a backup of it and tried to restore that on the 5.2 server; that's where the errors I posted came from.

I did make a little progress. I've got 5.2 running on another PC as a VM, (my "this is really gonna break something" tester). Restoring the 4.12 db here caused the same problem, and backups that I know are good couldn't be restored.
I went on the 4.12 server, changed all the encryption keys and backed up the database. Restored a good copy of the 5.2 image and restored the new db back to it, and that's up and running.

So, it looks like the problem is some kind of corruption in the database encryption, and at this point it looks like my 5.2 test server is hosed.