Worst night ever.

First, things are breaking down left and right. And to make my day the worst it could possibly be, I had the worst time with Aloha POS tonight at the restaurant. Somehow, the TRANS.LOG file for the day became corrupt. I lost all information for the day (server sales, reprints of checks, restaurant sales, and all associated reports). I tried to force close the day and move on to the next, but it refused because it couldn’t grind the TRANS.LOG. If any of you fellow Aloha users stumbled upon my site in hopes of a solution to the problem, I didn’t figure out how to solve mine. The only useful information I found was:

From http://www.tek-tips.com/viewthread.cfm?qid=1088470&page=2

To repair a corrupt log for the current day’s business, stop the FOH on all terminals, rename the Trans.log to BadTrans.log, open a command prompt and navigate to the Data folder on the file server. Use Grind.exe or GrindQ.exe to repair the transaction log on the file server using the following command line:

..\BIN\GRIND.EXE /FIXLOG BADTRANS.LOG

Grind does not alter the original transaction log (renamed BadTrans.log), but, instead, creates a new transaction log labeled Fixed.log. Once you repair the log, you must rename Fixed.log to Trans.log and restart the FOH terminals.

To repair a corrupt log for previous days business, open a command prompt and navigate to the dated folder on the file server, repair the transaction log in the dated folder using the following command line, and then manually regrind (refer to document AKBID1016) the dated folder:

..\BIN\GRIND.EXE /FIXLOG TRANS.LOG

Grind does not alter the original transaction log, but, instead, creates a new transaction log labeled Fixed.log. Create a backup copy of the original transaction log and rename Fixed.log to Trans.log.

I thought that it would work, but it didn’t. I then found a copy of Fixlog Utility for Aloha 5.2 and up from here. I think that would normally fix most errors, but my TRANS.LOG must have been F***CKED beyond belief.

Since I couldn’t move on to the next day, my solution was to backup my messed up TRANS.LOG in hopes of restoring it one day. In the meantime, I moved the previous day’s (functional) TRANS.LOG into the /DATA folder. It allowed me to move on to the next day. The only problem is that you’ll have two similar days worth of sales. In the meantime, I’ll try to figure out how to restore that corrupt log and post back with the solution.

P.S. I know absolutely zero of you care and/or understand this, but I just had to write it down and get it out of my head.

EDIT: It would be negligent of me to not thank my buddy Jacob for helping me through this trying time.

4 Comments »

  1. Lawrence Sheed said,

    September 27, 2006 @ 6:57 pm

    Actually I found this useful.

    One of my clients Aloha systems went down, had to reinstall the server, then was getting errors about TRANS.LOG.

    Aloha tech support was *not* very helpful at all. Talk to your reseller they said. So I asked, ok, who is the reseller for China, oh - there isn’t one. Great service. 10 minutes on the phone so I could have no help whatsoever.

    A little bit of googling and trial and error, and I copied over the previous days trans.log to the DATA directory, and up and running again.

    My client vows never to get another Aloha system again after listening to me on the phone with their support.

  2. Eric said,

    May 2, 2007 @ 9:17 pm

    Hi,
    What you can do is to backup the Data folder in AlohaTS for table service or AlohaQS for Quick service.

    After backup, delete trans.log from the data folder. You will be able to get the POS up and running. Only concern is the sales will be resetted to zero.

    You email me the backup zipped data folders to me, see if I can help you to recover the sales for that day.

    I have been supporting Aloha for 5 years with not much of a mayor issues. Trans.log corruptions is not common in Aloha. Could it possibly a hardisk error or bad sectors.

    Eric

  3. Mike said,

    September 11, 2008 @ 8:00 pm

    My system went down thirty minutes ago with that error - my local support people were unavailable.

    Regrinding the current trans.log and renaming the fixed just did the trick.

    Phew!

  4. michael said,

    September 15, 2008 @ 10:02 am

    I’m glad this post is helping other people.

RSS feed for comments on this post · TrackBack URI

Leave a Comment