Micros 2800/3700 database rebuild question

[willough]

We have a number of older Micros systems with the combination of 2700/2800 terminals and 3700 backoffice computers running NT. A few weeks ago I needed to restore a database and log one day from an automatically created backup and since that time the nightly backup routine itself no longer completes successfully - it produces a db.bad file rather than db.good. I have been told to run the Database Rebuild utility from the backoffice computer and this should correct any database mismatches that may have occurred.

When we run the Database Rebuild we seem to be returning to some point from a couple of years ago. That is, new employees are gone and those from the past are in the rebuilt database; ditto for products, pricing, etc. As if we have restored an older database rather than having rebuilt the current one. I have taken any other instances of the database and moved them to avoid choosing the wrong db for the rebuild. When prompted, we have pointed to the current db to rebuild.

We have tried the rebuild a couple of times and when we realize it hasn't worked we restored a backup, so no harm has been done.

I would appreciate some pointers as to a) what might be happening during the rebuild, and b) how can I accomplish the rebuild successfully? Thanks in advance.

 

[willough]

Here is the log that was saved from the rebuild. It didn't take anywhere close to the time indicated. I would say it was complete in under 30 minutes and the db is 200 MB.

03/25/2008 7:20:43 PM: Renaming database file from micros.db to microsRB.db
03/25/2008 7:20:43 PM: Resetting log file name for microsRB.db
03/25/2008 7:20:43 PM: Unloading database file D:\MICROS\Database\Data\microsRB.db
03/25/2008 7:20:43 PM: Unload command line options: -u -y -j 4 -c
03/25/2008 7:20:43 PM: Please wait...This operation may take a while
03/25/2008 7:20:43 PM: A 200 MB DB unloads in about 50 minutes
03/25/2008 7:20:44 PM: Initializing new database file
03/25/2008 7:20:44 PM: Command line options: -b -p 4096 -t
03/25/2008 7:20:47 PM: Starting newly created database
03/25/2008 7:20:59 PM: Loading dumped definition and data into the new database
03/25/2008 7:20:59 PM: Please wait...This operation may take a while
03/25/2008 7:20:59 PM: A 200 MB DB reloads in about 90 minutes
03/25/2008 7:36:22 PM: Stopping the database
03/25/2008 7:36:29 PM: Completed rebuilding of the database

 

[willough]

Can anyone contribute some assistance? Thanks.

 

[pmegan]

You can try reloading the software, but it sounds like you're going to have to get Micros involved. Rebuilding the database just unloads the data, drops in an empty shell database and reloads anything that still has data integrity. It doesn't pull data from anywhere except the database you're rebuilding, so if those old employees and prices aren't in the original you've got a twilight zone situation going on.

I'm a little confused by "log one day from an automatically created backup". Is this trying to apply a database log file after restoring?

 

[willough]

To clarify, one day I was trying to restore the database and the log.

By way of follow up, the problem still isn't resolved but I brought the database and the log to another Micros backoffice computer that I have, figuring I could try the rebuild on it, rather than the problematic system. Both computers have the same version info. The rebuild process looked like it was going OK for awhile as I watched the db rebuild and then I got an error message that the SQL Anywhere user name and password were not valid. And the rebuild terminated. I have no record of that user/password combo so I am back to square one.

Anyway, thanks for the feedback.

 

[Jrk3]

What version of Micros is it (I'm guessing < 3.2)? And more importantly, why do you need to rebuild in the first place? Is performance really bad?

No one seems to have given you an answer on your "b" question, so here's my 2 cents. Since it's reverting to what seems to be and old copy, I'm guessing that somehow, even though the rebuild fails, that it is, perhaps somehow reverting the database that is contained in an old microsRB copy.

I think you should return to the original server, and before starting the rebuild process, delete (or move aside) any instances of microsRB.db files in the Database\Data directory. Then start the rebuild process and see if it succeeds.

But you should feel lucky about just having to deal with a rebuild issue, as in my case, I have to deal with a 2.6 server that is never able to pass verification, therefore, it doesn't backup with a "good" copy and hence no backup is done.

 

[willough]

By way of follow up the rebuild is now complete.

Jrk3, our version is 2.60c like yours. We needed a rebuild because our nightly backup, also like yours, was not verifying and thus not producing 'good' copies. We were also having other problems including the need to start the db manually. The rebuild cleared up all of those issues in addition to slightly reducing the db size, from 163 MB to less than 150 MB.

We were unable to complete the task ourselves and had an outside firm help. They reported "the current micros.db database file was linked to the backup micros.log file from March 4th, instead of the current micros.log file. We unlinked the database from the backup log file, created a new log file and linked it to the current database. We ran the srvdb.exe application to repair any minor database issues (if any) that might prevent the Rebuild from running properly. We then performed the database Rebuild which completed successfully." It's been a few days since the rebuild and so far so good.

Hope this can be of some use to others as the amount of information online or in print about these older systems is not plentiful. Thank you and pmegan for assistance.