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

AlohaMGR, can't login after rebuilding disk

Status
Not open for further replies.

Beesboss

Technical User
May 2, 2011
20
US
I had another HD crash and have rebuilt the computer, got it networking fine (sees TERMs, Terms see it, Shares are indicated). But time ran out on redundancy this AM, and I can't get control of the AlohaMGR (6.5.16 on XP), all logins fail with this this error message:

(The user could not be validated for login to the system)

The old login Userid and password does not work.

Before I lost redundancy, I had taken a userid and assigned a numeric password, Copied the DATA folder from the term to the server, made a NewDATA folder from that and deleted the trans.log file. Still no luck.

I am getting the feeling that the it's not picking up whichever DB file contains the employee database.

So I think I am at the point where I have 2 options:
Refresh the 21 days by installing the HASP on the Master, which I tried. I think there must be more to it than just installing the HASP driver with the USB Key, which does light up BTW, in place (per Coorsman,whom I respect). I also tried the SwampGas trick, deleting trans.log, I did that after closing Aloha on the Term, but that did not change the redundancy (error message after entering emp #, then returns to the keypad page).

The second option would be to get help with a usable database i could overwrite the existing one with and and then use the known ID/Password to get in. At this point I have no problem with having to re-setup all the employees (I can assign that to the idiot who didn't tell me the server went out)

If there is a third option, I am open. However, I really need very concise instruction, as I am only as good as I ever was any more (or something like that).
 
Run the program dbconfig.exe from the aloha\bin folder on your server - click on run the yes. This should upgrade your current data and newdata folders you copied from the terminal.


Cheers,
Coorsman
 
Coorsman, Thanks for the quick reply.

I am not having success. I am working through what may have been my mistake in capturing the password resetting, so I have 3 sets of DATA folders to try. But first, I need to confirm with you the dbconfig settings, per the list below:


Selected checkboxes are:
DBF files only
Attended
Debug-mess...
Force Version Upgrade

Unselected checkboxes are
Create DBF File
Enterprise lds
Central Site lds
Assign Security Levels
Configuartion Data Only
Do Not Copy DBF Files

All "Advanced AeM Options" are Unchecked

Iberdir C:\Aloha (originally C:\AlohaQS)
Input C:\Aloha\NEWDATA (originally C:\AlohaQS)
Output C:\Aloha\NEWDATA (originally C:\AlohaQS)

These were the defaults. Do you have other selections?
Respectfully, beesboss
 
Hang on a sec. You set a password before you lost redundancy... Does that mean you assigned an existing employee a password on the front of house? That's not going to get you into Aloha Manager.

Do you get any other errors when you start Aloha Manager? With the old username and password that don't work; do they fail with the same "could not be validated" error, or something else? If you get the same validation error with credentials that should work (the old ones) and ones that should fail (some random bogus employee number), your problem may not be the credentials themselves, but the validation process. Make sure the services and their associated DLLs\OCXs\whatevers are registered properly, the Windows account that the services use is an administrator and has "log on as a service" rights, and the service configuration has the correct user\password combo (capslock?).

Also, the Million Dollar Question: what's the debout say? You should have a TMP folder in the Aloha folder on the fileserver and terminals. See if there are any clues on the fileserver in debout.txt and\or debout.svr. Just be careful about posting chunks of them here: it would help, and we'd be happy to peruse them for a fix, but make sure there's no sensitive info before you post it, and XXXXX it out if there is.

I'd just pull the DATA and NEWDATA folders from the master terminal, put them in the Aloha folder on the fileserver, set the server's IBERDIR and IBERROOT variables to point to the Aloha folder, reboot, and do the install from CD again, but slower, especially the part where you're asked if you want to use a sample database. If the data is in the right place, the variables are correct, and everything else lines up, the database selection options should be grayed out, and you should eventually get a message about the presence of existing data that the install will make use of.

Good luck.
 
Majic,
Thanks, and thanks also Coorsman, for talking me off the ledge...
Majic, what you said rang a bell, as IBERDIR did not point at Aloha, so I knew the install was not right.

Reinstall came right up with NP. All I have to do is mop up the redundancy, and I'm back in biz. Thanks again
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top