Technical Teams, Database Administrators, and Product Development
Description of Issue:
Error 32 - (0xC0068032) - Aloha causes a failed order with this error:
2020-07-14 15:49:07.9300|2020-07-14 22:49:07.9300|INFO|COM error when committing order 708617443 System.Runtime.InteropServices.COMException (0xC0068032): Exception from HRESULT: 0xC0068032
Table in use
1. This issue is caused by an order coming across to POS with the exact same name as another check that is active and open. Starting in Aloha 12.3, this is not permitted and a 32 error is thrown. This means that there can be an open check named "Bob Marley" and if "Bob Marley" tries to place another order, POS will respond with 0xC00680032. However, if he places a second order as "bob marley", then POS will allow it because there are character differences.
2. This can also be caused by locked Validation checks (DO NOT MAKE checks). You may have noticed in your logs that there are Validation orders called "DO NOT MAKE 1", "DO NOT MAKE 2", "DO NOT MAKE 3" up to "DO NOT MAKE 20". In some cases, Aloha will not allow a "DO NOT MAKE n" check to be cleared and closed, thus causing a 32 error when that locked "DO NOT MAKE n" is up for its turn as a Validation check name.
1. To avoid this, Olo added a POS Configuration to add the last four digits of the order number to the check name. This is activated with "AddOrderIdToCheckName=True". When this is used, Bob Marley would have checks named "Bob Marley1234" and "Bob Marley5678" (assuming 1234 and 5678 are the last digits of the Olo order IDs.
2. Currently, the solution is to address the stuck Validation check by deleting the .lck file out of %iberdir%\data. On occasion, a restart of the OloAlohaService will address the issue because it forces a restart of iber(qs).
3. Relief from this error has been observed with the CloseZeroDollarChecks configuration being set to True.
1. Review your Olo log to determine which check invoked the 32 error. If it was a real customer name that generated the error, then contact you CSM or your POS Technical Specialist (if in deployment) to have them enable "AddOrderIdToCheckName=True"
2. Review your Olo log to determine which check invoked the 32 error. If it was a "DO NOT MAKE n" check %iberdir%\data for an .lck file that corresponds to the stuck validation check and contact your POS IT team to remove it and/or restart OloAlohaService.
Olo is working to increase the Validation checks up to "DO NOT MAKE 99" to broaden the workaround while restaurants are busy.