Micros technician in Mass or online!!!

[criollabonita]

Hi, I am looking for someone in MASS that can help me with my POS network. I need to re-build the database and I am being charge way too much from Micros to have a tech on-site. Need help please reply if you know of a tech that can do this on-site or through webex. Thanks

 

[savissimo]

What seems to be the problem?

 

[criollabonita]

the systems always loses communication with the data server. It seems to crash at least once a month. I have to reboot the computer several times to get it back to the server. Recently 3 bartenders were locked out with the message " cannot clock in before last clock out". I try to figure out what was the problem and everything seem ok. Finally the message has gone away but now the message is "2669 closed checks have not been purged" I have checked the. I have checked the end of the night reports, any open checks, purge historical total, etc. It seems like there are several weeks missing. Also the journal Zip has not been recording for a while. etc. I think we may have to rebuild the data base but i am not sure if i am going to be able to do it properly on my own.

 

[savissimo]

What version of micros?

 

[CathalMF]

the "cannot clock in before last clock out" happens if the employee is clocked in on the system at a date and time ahead of the current date and time. Can happen if someone changes the time on the server.

"2669 closed checks have not been purged" is caused by the purge step in the end of day not working correctly for what ever reason.

to resolve this login to dbisql custom/custom
execute the following query to find the last purged date.
select min(business_date) from micros.trans_dtl

This will return the last purged date.

execute the following to update the purge
call micros.sp_purgehistory()

This command may take a few seconds to 30 minutes or more depending on how much it needs to purge and it will probably need to be run many times to get everything purged.
run the select statement every now and then to check if the purge date is updating.

To rebuild a micros database is easy.
in version 3.* shutdown micros database and go to start -> programs -> micros applications ->utilities ->database -> rebuild

browse to the micros.db and rebuild it.
Always make a copy of the micros.db file before doing this.

in 4.* go into the database manager and there is a rebuild option in there. i cant remember exactly where.

 

[CathalMF]

as a note to my above post.
the purge date will update to a maximum of 14 days previous to the current business date. this is correct.

 

[pmegan]

Definately check the system date before running the purge. Getting that number of checks not purged all of a sudden sounds to me like the system date has been pushed ahead. This, combined with the error those bartenders received, makes me think that somebody is playing with the time on the Micros server; probably accidentally looking for vacation dates or something similar. This was happening in a few of our stores until I removed windows privileges to the system time; then the problem mysteriously stopped.

 

[criollabonita]

Thank you very much for your replies. This website is amazing thanks to all of u. There is one more thing i am concerned about. The zip journals have not ben saving information for little less than one year. Autosquence-reports has information of all that time but to review detail info about each business day with the ZIP it is not possible. I would like to know how I can repair this issue. i thought of re-building the database because i think that am having all these issues due to lack of space in the server. What do u think?? we have a RES 4.0 HF1

 

[pmegan]

What zip files are you referring to, the logs & journals or something else?

How big is your database? If it isn't purging it can grow pretty fast. Between that and the daily backup of the oversized db you can really chew through disk space.

Here's what I would do.
- Clean up the hard drive. 4.0 was pretty good at throwing temp files all over the place and forgetting about them.
- Check the business date in manager procedures and make sure it's correct.
- Run a time card report and check out the shift lengths. If you have anyone clocked in for over 24 hours, or with shifts that end before they start, adjust them in Manager Procedures.
- Run Open Check and Clock In status reports. Close any checks that shouldn't be open.
- Run the SQL queries CathalMF provided:
[blue]select min(business_date) from micros.trans_dtl[/blue]
if the result is more than 14 days old, run a purge and another business date query:
[blue]call micros.sp_purgehistory();[/blue]
[blue]select min(business_date) from micros.trans_dtl[/blue]
Repeat this until the date returned is 14 days old. The system will not purge anything new than this, so that's the date your shooting for.

If the date stops changing at any point beyond 14 days, you most likely have 1) an check that's been open for more than 2 weeks, 2) an employee who's been clocked in for more than 2 weeks, or 3) some kind of db corruption. Check the labor and open checks again.

Once you get everything purged, back up the database and rebuild it. Both are done through Database Manager.

If the purge stopped short of 14 days and the labor & checks look ok, back up, rebuild and try the purge again.

Depending on the size of your database and how long it's been since the purge worked, this may take a while. Purging will low the system down quite a bit, and you can't access POS operations or any of the Micros applications during a rebuild, so do this when you can go a few hours with the Micros system.