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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Aloha 6.1.30 error at terminal

Status
Not open for further replies.

IronChef1

Technical User
Apr 9, 2014
2
US
I am receiving a error at the master saying z:aloha\data\translog c:aloha\daya\trans.log Help me please POS is down
 

Look at the FAQ's in the menu above this page -

faq693-7517 - how to repair a corrupt trans.log file.


Cheers,
Coorsman

 
Since your trans.log is in the data folder and not in a data folder the steps are a bit different than the instructions in the post.
First from aloha manager
Goto Utilities, stop front of house

Open a command prompt by typing CDM at the run command
now type this in the command window
after each line press enter

cdcd %iberdir%
cd data
ren trans.log badtrans.log
..\bin\grind /fixlog badtrans.log
ren fixed.log trans.log
exit

Go back to aloha manager,
If the trans.log is fixed you should be able to run a sales report for todays data. If the report comes up then go to Utilities start front of house.
You may have to reboot the front of house terminals if they don't restart.

Let us know your results

AlohaRoss
 
This isn't usually the problem, but when you see this message, always make sure it's doesn't say corrupt at position zero. It will do that if the date is way off on the terminal sometimes, like when you lose your BIOS settings.

Also, not really a "fix" per se, but if you're in the type of emergency where you just need the system up and don't care about the sales history (an hour into a new day of business, for example), then you can always delete the trans.log which is like starting over the day. But you will lose your sales history for that day.
 
The problem was somehow the share file on the BOH server was changed to read only. Problem fixed
 
Thanks Ross.

I know places with corporate places where the head office might not love the idea, but I deal with some small mom and pop type places where you're dealing directly with the owner or the GM. They don't really care i the numbers are a little off, they just want the system up even if the place has been open for 8 hours. Sometimes you get lucky and other terminals still running and servers can print off and then re-enter their checks, too.

But every call with a corrupt trans.log, I pretty much tell them right off the bat that we can attempt a fix, but it doesn't always work, in which case we may have to delete it. Sometimes they are a little panicked about it at first, but after a minute or two they realize they'll survive- and the on the bright side, they'll immediately have their system back.
 
First off, you should never delete a trans.log. If it's an emergency and the place is packed. Best thing to do is rename the trans.log. This will still create a new trans.log and from there you can merge and fix the log after end of day so the site will still maintain some sales and labor data.

I've been able to fix 99% of corrupt log issues. Some fix right out the gate with just a fixlog and some don't and require what i call the 50/50 split or manually zapping corrupt offsets in the log.

 
A 50/50 split is done when after a fixlog is done and grind still errors out.

the process is tedious.

1. split the log in half and grind each half of the log and see which half errors out.
2. from the trans.log that has the corruption, you would split that log again in half and repeat until you can isolate which area of the log is corrupt. Split that portion off and merge them all back together and regrind.

This process is only done if you zap multiple individual offsets and it still fails to grind.

Pew Pew! bye bye offset...j/k.

i manually zap offsets using a program i created. took me 2 year in the making.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top