We do a lot of large, large groups. We continually ask our servers to keep smaller bills for the groups....one for beer, one for wine etc. It seems though every few months we get one bill that gets to much rung onto and crashes with chk_dtl read fail and we can't pick it up again. We end up forcing it closed. We don't get a warning that the check is getting to large. Is this something that can be done? When 80% of the detail is full a pop up or something? Our database goes back to pre version 1....could that be the issue? Thanks
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 biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Micros large checks crash into Chk_dtl read fail
- Thread starter Wildbar
- Start date
- Thread starter
- #3
I don't know if this will be the problem, but what do you have the maximum details per check set to? Earlier versions of Res choked if this was set high, so the suggestion was to set it pretty low, so if your system has been upgraded a few times this may have been carried over. It should however give you a "transaction file full" message if you exceed it though, not a read failure.
Read failures usually occur when theirs a comm issue while the check detail is being written, often due to a power fluctuation at the workstation. The write doesn't complete, so the next time you pick it up you get a read failure on the check details. My guess would be that it's not the number of items on the check, but the length of time it's taking to write those long checks back to the database. If you have some kind of intermittent power or data drops going on, the big checks would be more open to being affected.
Read failures usually occur when theirs a comm issue while the check detail is being written, often due to a power fluctuation at the workstation. The write doesn't complete, so the next time you pick it up you get a read failure on the check details. My guess would be that it's not the number of items on the check, but the length of time it's taking to write those long checks back to the database. If you have some kind of intermittent power or data drops going on, the big checks would be more open to being affected.
- Thread starter
- #5
Way way back the Micros gurus set it to 999.....the max. So I am thinking we don't want it to be there. What would be a standard setting for this? We have this issue at several locations and it typically only happens with large large cheques We do get the odd chck_dtl read failure from workstation power issues etc but have always thought this was more a software issue.
Thanks in advance
Thanks in advance
I've got it set to 999 in all of our restaurants and haven't had any problems. The database they're all based on is also pretty old, started as a 2.0 DB. Some of our restaurants have 350+ seats and get massive checks like that when we have shutdown events.
You'll probably have to do a little bit of investigating to see if there's a size threshold that's causing your checks to crash.
Try running this, substituting the #'s with any of the problems checks you have from the past 14 days, and see what the num_dtl count is.
If they're all about the same that might give you an idea of the problem size. Micros uses 30 lines just for info lines and tendering, (38 if you use 16 info lines), so keep that in mind if you change the number of details allowed.
Also, how big are your databases and when is the last time they were rebuilt? There's always a change this could be coming from some kind of corrupted data in the detail tables.
You'll probably have to do a little bit of investigating to see if there's a size threshold that's causing your checks to crash.
Try running this, substituting the #'s with any of the problems checks you have from the past 14 days, and see what the num_dtl count is.
Code:
select c.chk_seq, c.chk_num, c.num_dtl, c.num_mi_dtl, c.num_chk_info_lines
from micros.chk_dtl c
where c.chk_num in (#,#,#)If they're all about the same that might give you an idea of the problem size. Micros uses 30 lines just for info lines and tendering, (38 if you use 16 info lines), so keep that in mind if you change the number of details allowed.
Also, how big are your databases and when is the last time they were rebuilt? There's always a change this could be coming from some kind of corrupted data in the detail tables.
- Thread starter
- #7
- Thread starter
- #8
Ok, so there were about 550 detail lines on that check. It would be great if there was more than one check to help develop a pattern, but you can try setting the number of lines to 500 and see if that stops it from happening. The only downside is that if you hit that limit in the middle of an order there's no way to override it. You'll have to either send part of the round and finish up on another check or cancel out and enter the whole round on a new check. On the plus side, if the servers have to cancel out and ring a couple dozen items again it may convince them to begin multiple checks from the start like you've been asking them to.
FreeSoldier
Technical User
Folks,
I would appreciate if someone could tell me where I can set the number of maximum transaction. Some of you had mention 999. We have the same problem on check for private event when the number of transaction exceed a limit and the check become uneditable.
Thanks in advance for you help
I would appreciate if someone could tell me where I can set the number of maximum transaction. Some of you had mention 999. We have the same problem on check for private event when the number of transaction exceed a limit and the check become uneditable.
Thanks in advance for you help
- Thread starter
- #11
FreeSoldier
Technical User
Thanks Wildbar.
Ours is set to 999 as well.
I noticed that discounts are counted as part of the total transaction and can create double the amount of transaction for each discount. (i.e. if the check has 20 transaction and you do a global discount for example marketing for a set $ amount, it will eat up another 20 transaction as the discount is applied proportionally for every transaction). For buyout and large party you can reach that limit quite quickly.
Best
Ours is set to 999 as well.
I noticed that discounts are counted as part of the total transaction and can create double the amount of transaction for each discount. (i.e. if the check has 20 transaction and you do a global discount for example marketing for a set $ amount, it will eat up another 20 transaction as the discount is applied proportionally for every transaction). For buyout and large party you can reach that limit quite quickly.
Best
Voids and discounts do take up lines, but running over the maximum details doesn't give you a "check detail read failure".
If you just add too many items onto the check, or if the voids or discounts will add too many lines, you get a popup saying "Transaction File Full".
If you try to order and discount items within one transaction, and the discounts push you over the limit, you'll get a popup saying "Insufficient Space In Trans File".
In either case, you can pick up the checks and split items off to take care of the voids or discounts.
"Check Detail Read Failure" is telling you that the check details written in previous rounds are incomplete or corrupt, so the check can't be read in to be picked up. My guess would still be communication or power fluctuations during the long write times on these checks, not necessarily the size of the checks themselves.
If you just add too many items onto the check, or if the voids or discounts will add too many lines, you get a popup saying "Transaction File Full".
If you try to order and discount items within one transaction, and the discounts push you over the limit, you'll get a popup saying "Insufficient Space In Trans File".
In either case, you can pick up the checks and split items off to take care of the voids or discounts.
"Check Detail Read Failure" is telling you that the check details written in previous rounds are incomplete or corrupt, so the check can't be read in to be picked up. My guess would still be communication or power fluctuations during the long write times on these checks, not necessarily the size of the checks themselves.
What is your power environment? 100% clean. Dedicated circuit? Are any POS devices plugged into GFI outlets? Are Kitchen printers plugged into clean power or are they plugged into heat lamps, warmers, steamers, line coolers, coffee machines etc etc.
Examine ALL your network connections. I'd bet a weekly paycheck that you have a soiled network connection. Unplug every network cable and examine the cable and the connector; is it dirty, corroded etc.
Examine ALL your network connections. I'd bet a weekly paycheck that you have a soiled network connection. Unplug every network cable and examine the cable and the connector; is it dirty, corroded etc.
- Status
Similar threads
- Locked
- Question