A file that is marked as read only whether via user rights or because it was dragged/dropped from media that is read only is the most obvious cause, although usually isn't the cause. Ensure that the user has both read/write rights (and since in some versions temporary files are created, the user needs delete rights to data folders as well). Most commonly this happens when a new client PC is added to a network and the user's rights are insufficient.
 |
| File forced to be read only and the result when that file is attempted to be written to |
Another issue could be an older formatted Btrieve file. As users move forward to newer versions of the software and deploy newer Pervasive versions, some of their files may be in an older format that starting with Pervasive 9.x (now considered legacy since the latest version currently is v13 released in 2017), Btrieve 5.x and older files can be read but not written to until they are rebuilt (or "reindexed") into a newer format (6.x or above but 9.5 is the usual standard even with later releases). A rebuild utility is provided with the Actian/Pervasive engines and is the best way to resolve. Our reindex program, as originally developed by Business Tools, can globally identify the format level of a user's files in a given company.
 |
| Older format causing status code 46 format determined via a BUTIL -STAT |
Another possibility is the use of an owner name where an incorrect owner name is passed when the file is open. While the underlying programming language supports owner names, owner names are normally not used in Advanced Accounting programs, and so this cause can normally be ruled out.
A mixture of Btrieve 6.15 and Pervasive/PSQL engines can lead to a status code 46. The two engines cannot be used to access the same data files simultaneously. Different PSQL various normally can be used safely together although it is best that all PC's use the same version.
The most difficult situation involves outside applications or processes that may be scanning, copying or indexing the data files. We previously made brief mention of status code 46 issues with respect to online or live database backups and these are the the most common cause.
This issue has been known for sometime now but can be very difficult to troubleshoot, and it can lead to significant loss of data should it strike. Typically we have something like four or five support calls every year where the end user has lost data as a result of a status code 46 issue, whether observed as such or not.
The peculiarity relates to how the Btrieve API reacts to a file that is being copied or scanned and when it then tries to open that file while no other instances of that file are open by anyone. If the file that is being copied or scanned was already open by the Btrieve engine on some client/workstation prior to initiation of the copying or scanning, there is no issue. But if no user has the file open, and the copy or scan begins, and then the file is opened through say the accounting sofware, the Btrieve/Pervasive engine opens the file in a read only mode, and that is not easily detectable. Only later when typically a record is attempted to be saved to that file will the 46 result and usually in the middle of a posting process. The user at that point is able to click on OK and continue. And continue. And each time OK is pressed, a record in that file is effectively "lost." And once this starts to happen, a domino effect occurs to other users who try to access the file and write to it, and the 46 status remains until all instances of the file are closed (even though the copying or scanning process may have long since completed).
It is larger files that take longer to copy or scan that are the most vulnerable, and these often are also some of the more important files. If all files were all opened all of the time, this kind of status code 46 could never happen (placing all files in continuous operations mode avoids the problem for backup purposes, but places a heavy overhead on a system). Keeping all of the files open all of the time however is normally very inefficient and isn't what happens in a typical Advanced Accounting program. Files instead that are needed in a given program option are instead opened at the beginning of that option and they are automatically closed when that individually selected program option ends (or can be closed earlier programmatically). This normal internal structure combined wiht the behavior of the Btrieve API can, albeit under somewhat rare circumstances, lead to situations where no files are opened by anyone and then suddenly an online backup or anti-virus scan of some kind starts just before a user than starts a program than opens that same file, and it if is a file that is later written to or deleted (such as in a posting program), status code 46's can result.
Anti-virus software has been suspected of triggering this issue. Your data file folders should be excluded from real time anti-virus scanning (data files cannot become infected, and this is something that is desirable in any event because it will improve performance). In our experience, the 46's have always been tied to some sort of backup or copy operation that was in progress when a user then unknowingly selected a posting program that opened the same file that was being copied, with no prior instances of the file having been opened by a Btrieve engine.
For one user that was having a problem when copying data files off late in the afternoon to laptops and another that was having nighttime backups taking longer and longer and were still running in the early morning hours (including 5.1 versions in fact), we added some logic when records were being saved to detect this issue. But that doesn't prevent the problem in the first place and further when it happens, the user can't usually easily resolve the problem on their own. Therefore we have recently implemented some new logic where we test the most exposed/larger files that are going to be written to in advance to detect if the file is being copied or is being accessed in some manner from outside of the software (and if the copy started before the file was opened by any accounting software user). We have implemented this newer logic in the SO-G posting program in the latest versions of Advanced Accounting, and will be adding it to others.
Note that when posting sales orders on the fly, the AR invoice header file (BKARHINV) is already open in Advanced Accounting because it is needed to check for previously assigned invoice numbers. So when that sales order is then posted right after printing or a print preview, a status code 46 would never result but rather only when posting sales orders in a batch (normally a good thing). The general ledger transaction file (BKGLTRAN) in either case however would still be vulnerable and that is a file that we also "pre-check."
How can you avoid status code 46's in the situation as last discussed above?
(1) Exclude data files from being scanned in real-time. As noted, it can actually be helpful to have other users utilizing the software keep certain files open during posting processes that can, counterintuitively, help with this access denied status code (although they can create other problems by locking customer or inventory location records).
(2) Use of continuous operations mode can also help to avoid the issue. But most importantly, ensure that scheduled backups are taking place well outside of normal operation times and monitor them to ensure they don't start to creep into the early morning hours.
Note: if you are making a manual backup copy of a file on a system that is live and that is fairly large in size and will take more than a few seconds to copy, it is actually safest to first open that file (either in maintain database or in some program that you know opens it) prior to making the copy. Otherwise your file copy request, if the file is large enough, could cause a live user to experience a status code 46.
No comments:
Post a Comment