A Case of Btrieve Error 046 on ARCRCLOG A/R Credit Card Log File
Version: All
Q - We are getting the following error in Elliott when we process a credit card transaction. It seems the credit card transaction did go through because we can see it in the payment portal. But we consistently get this message at the end of processing a credit card transaction. Could you let us know what it means?
Case Study
We called this user and used Teamviewer to investigate this issue together. Indeed, we can recreate this error. When the above Btrieve Error 046 on ARCRCLOG window shows up, we click on the "Details" button. Then we use the slider to scroll to the end of all the entries. Here is what it looks like:
The last entry shows 0046 on the ARCRCLOG table, and this confirms the exact error number and table. Since in some situations the error code and table in the prior window may not match the one in the "Detail" window, we are taking this step to confirm it.
Now the question is why we are getting Btrieve Error 046 on ARCRCLOG? The following is an exaplanation of Btrieve Error 046 from the following KB article:
046: Access to the requested file is denied
The MicroKernel returns this status code for the following reasons:
- The application opened a file in Read-only mode and tried to perform a Write operation on that file.
- The application attempted to perform a Write operation on a file that is flagged Read-only by the operating system.
- When the application opened the file, it did not correctly specify the owner name required for updates.
- (Workgroup engine only) If a Workgroup engine user or task opens a file that a client machine has opened using a server MicroKernel, the MicroKernel returns this status code if the Workgroup engine user attempts to write to the file.
- (9.x and higher engines only) The application attempted to perform a Write operation on a 5.x format file. When using a 9.x or higher engine, you cannot perform a write operation such as insert or delete on a 5.x format file.
We verified all possible causes in above explanation and ruled them out. Now we go to the server and bring up PSQL Monitor Utility and find the ARCRCLOG.BTR file and see if there is current activity:
As we can see, the ARCRCLOG.BTR file table is opened by Windows user "deferred," which hosts the Elliott defer processing. This is strange because defer processing typically does not process tasks during the day. So we asked the user to access the server for the defer processing task.
As it turns out, that defer processing task was in the middle of posting A/R credit card transactions and it appears to be locked. We had to use the Task Manager to kill the Elliott defer processing tasks to stop the locked-up task. After that, we restarted the defer processing and made sure the defer processing can process the aborted task correctly. Then we asked other users to process their credit card transactions, and everything appeared to be working correctly.
Does it hurt when we kill the Elliott defer processing tasks that were in the middle of posting? Well, generally speaking you don't want to do this unless Elliott is stuck. When Elliott is stuck, you will have no choice but to terminate the Elliott task. All Elliott posting routines use a feature in PSQL called "Transaction." In the beginning of the posting routine, Elliott will declare to PSQL that the "Transaction" is beginning. At the end of the posting routine, Elliott will tell the PSQL that the "Transaction" is ending. If for whatever reason, the PSQL engine does not receive the "Transaction" end signal from Elliott, and the same Windows user makes a reconnect request (like in this case), PSQL automatically aborts the previous update after the "Transaction" begins and rolls back the changes. This is a great feature that protects the Elliott database to ensure data integrity.
One of the downsides of utilizing "Transaction" is excessive database locking. Because the PSQL engine needs to ensure that it can roll back in the case of failure, it will lock not just on the record it changes, but also the index pages that are affected, so the locking is much more widespread than just the records that are updated. As a result, when the PSQL is in the "Transaction" state, there could be more locking on the database than expected.
Typically, a posting routine will not take long to complete and if the posting routine takes place at night, then the locking of the PSQL "Transaction" state and its impact to the Elliott system is minimal. In this case, because the posting is locked up, it created the locking condition for an extended period of time.
The lesson we can draw from this incident is that the error 046 can be caused by "Transaction" state locking, which can happen during the Elliott posting routine. If the posting locked up, then the problem can exacerbate and cause unexpected locking conditions for other users.
EMK