Restore Db Failed (the User Account Does Not Exist)

[PDECODE]

I try restore DB with command "prorest d:\DB\dbname dbname.bak" on Windows system and i get this error:

OpenEdge Release 10.2A as of Mon Nov 3 22:05:01 EST 2008
Authentication service error in login process for sysprogress [OpenEdge] - The user account does not exist (13336)
User authentication failed, the database operation cannot be performed (13313)

I have more backups but all are restored successfully. Just only this one has problem. It looks that inside backup DB doesn't exist sysprogress user? But how was then backup created? Any other parameters -vp | -vf | -list fails with same message.

Any clues how to restore this backup?

 

[RealHeavyDude]

Never had this one during prorest. To my understanding offline backup/restore should never rely on a user in the _User table.

Are you trying to restore over an existing database?

Heavy Regards, RealHeavyDude.

 

[PDECODE]

No, it's just restore to empty directory. There is also no server running yet. Later i will used DB in single user mode.

I found on PROGRESS knowledgebase article No: 000037941, where is similar problem but on UNIX which say:
Procopy, prostrct, prodel, _dbutil, and _proutil as well as many other Progress executables perform certain system checks to validate the user attempting to use the tool has the authority to use the tool.

What if the backup was made on UNIX and i want restore DB on Windows? But why previous backups from same package are restored Ok ...

Edit1:
Now i found that this backup has additional "File Area" section in *.st file in compare to other backups that works ... So i use original *.st file. Prorest doesn't recreate it to original state but if you provide some *.st file - prorest utility use it as defualt for restoring.

Edit2:
I try use PROGRESS 11.0 version prorest utility on my backup and i find that i can list/restore backup without this error. (but DB has incorrect version after, which is obvious) It looks maybe on some bug ...

 

[RealHeavyDude]

Okay, when a Progress database gets created, the operating system account under which it gets created, automatically becomes the owner of the database and is, amongst others, granted DBA privileges in the SQL security. Therefore one can successfully connect to a Progress database almost out-of-the-box via ODBC/JDBC using this operating system account for authentication. Usually, since one don't want to spread around the credentials of the operating system account, or they are not known, or for some other reason, a user SYSPROGRESS can be set up in the database which is automatically granted DBA privileges.

What I don't know is whether the existence of the user SYSPROGRESS in the _User table can have a negative impact when you are executing utilities like prorest with a different account as the one the database was created with. At least the occurance of SYSPROGRESS in the error message seems strange to me.

Has the database been created and/or the backup been taken with a different operating system account than und which you attempt the restore?

Just for the record: You can't restore a backup that was created on Unix on Windows and vice versa. The Progress backup files a platform dependent and can only be restored on the platform ( Unix, Linux, Windows ) on which they have been created.

Heavy Regards, RealHeavyDude.

 

[PDECODE]

SOLUTION: in session startup.pf file was forgotten "-U sysprogress" parameter and prorest utility take this information into account. Just commented -U and -P params and all worked well. I think that if you do first new offline with no-server DB restore - PROGRESS should ignore this setting.

 

[RealHeavyDude]

I fell into the same pithole when we migrated from OE10 to OE11. For some reason I took a backup with OE10 and restored it with OE11 without encountering any error message until I tried to access the restored database ...

+1 that this is a bug. The restore utility should raise an error whent it is run with a different version ( major ) than the backup has been taken.

As you've alread found out, you can only restore a database when an existing structure description file contains the same areas than the backup. You could remove the structure description but then prorest will create all exetents in the working directory. Therefore it comes in handy when you have a recent structure description at your disposal. Or, you can use the -list option on prorest to produce a list of areas contained in the backup.

Heavy Regards, RealHeavyDude.

 

[RealHeavyDude]

The startup.pf parameter file residing in the installation directory is used by any Progress process. Glad you found the root of all evil.

Heavy Regards, RealHeavyDude.