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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
check is stuck! 2
- Thread starter moodgrl
- Start date
-
1
- #2
jackandrews
Vendor
Could be an issue with the memory, try powering off the entire unit and waiting a bit. The issue sometimes is how the application writes into the memory can cause these hangups especially if their code doesn't shut down unneeded applications/components.
point of sale | Security Cameras
point of sale | Security Cameras
- Thread starter
- #4
I've had guest checks stuck open since April, I cleared totals and it wiped the checks out that were open, but now a few days later there are new checks that are now stuck open. I tried shutting system down and letting it sit for about 30 minutes. I've tried picking up these checks and the pc freezes. Please Help!!
-
1
- #5
I am not sure what version you are using, but I remember at one point there was a version that if you had an item on a check and its "Effective To" date had already passed, this would happen.
We had a place that would do lunch specials, and most of the time they were paid out by the 3:00 "Effective To" time, but sometimes if they weren't and the check was accessed after 3:00, the check would lock the workstation up.
Shot in the dark, I guess.
We had a place that would do lunch specials, and most of the time they were paid out by the 3:00 "Effective To" time, but sometimes if they weren't and the check was accessed after 3:00, the check would lock the workstation up.
Shot in the dark, I guess.
- Thread starter
- #6
Open DBISQL (Start --> Run --> dbisql)
2. Login: custom/custom
3. Enter the following SQL command:
SELECT * FROM micros.chk_dtl where chk_num=xxxx
(xxxx=Check Number that is needed to be closed)
4. Click Execute
5. Make note of the chk_seq number
6. Clear the previous SQL command and enter the following SQL statement:
CALL micros.sp_forcechkclose(xxxx)
(where xxxx=chk_seq number from previous command)
7. Click Execute
2. Login: custom/custom
3. Enter the following SQL command:
SELECT * FROM micros.chk_dtl where chk_num=xxxx
(xxxx=Check Number that is needed to be closed)
4. Click Execute
5. Make note of the chk_seq number
6. Clear the previous SQL command and enter the following SQL statement:
CALL micros.sp_forcechkclose(xxxx)
(where xxxx=chk_seq number from previous command)
7. Click Execute
Forcing them closed through SQL will get rid of them, but won't stop it from happening again.
Just a few questions to clear things up and try to come up with a solution that will stop this from what seems to be a recurring problem.
The description of the problem says that the PC is freezing, so I was wondering if you're picking up these checks on the PC or on one of the workstations?
Are you getting a "check detail read failure" error before the screen blanks out?
Is there any pattern to the checks that are acting up? Started from the same workstation, same time of day, anything like that.
Without any real details, my first guess would be that they're being accessed from the same workstation. Very often, recurring check corruption like this is due to power issues at one, or all, of the workstation. This could be due to just flakey power at the outlet, or something with a motor, (like a blender), or a compressor, (like a fridge), plugged into the same circuit as the workstation. If there's a check being sent on a workstation when the power dips it can mess up the connection to the database and foul up the write process for the check details.
Just a few questions to clear things up and try to come up with a solution that will stop this from what seems to be a recurring problem.
The description of the problem says that the PC is freezing, so I was wondering if you're picking up these checks on the PC or on one of the workstations?
Are you getting a "check detail read failure" error before the screen blanks out?
Is there any pattern to the checks that are acting up? Started from the same workstation, same time of day, anything like that.
Without any real details, my first guess would be that they're being accessed from the same workstation. Very often, recurring check corruption like this is due to power issues at one, or all, of the workstation. This could be due to just flakey power at the outlet, or something with a motor, (like a blender), or a compressor, (like a fridge), plugged into the same circuit as the workstation. If there's a check being sent on a workstation when the power dips it can mess up the connection to the database and foul up the write process for the check details.
- Thread starter
- #10
- Status
Similar threads
