Btrieve's Status 2 Status 2 is defined in the Btrieve manual as an I/O error, i.e., an error that has occurred during disk read/write. By nature of the problem, it is almost impossible to determine the exact cause of a status 2. Sometimes it indicates that the file is damaged and must be recovered. Sometimes your file is fine, but something else is wrong, such as your hardware, or a number of things you will see later in this article. We will also discuss some preventable causes of status 2. In general, the type of Btrieve operation that returns a status 2 can usually indicate which part of the file is corrupted, if the file is indeed corrupted. If status 2 occurs on an OPEN call, the header page of the file may be damaged. If it is returned on a GET operation, one or more key pages for that particular key may be corrupted. If a write operation (INSERT, DELETE, UPDATE) returns a status 2, one or more key pages for any key may be damaged. Status 2 on read or write operations may also indicate corrupted data pages. Once a key path is corrupted, you may be able to retrieve your records using any other key path. But, the problem still exists and will continue to exist until the file is rebuilt. If the header page or a data page is corrupted, you probably will not have any choice but to rebuild it. However, in all cases mentioned above, it is possible that there is a physical problem with the hard disk, where certain pages in the file can no longer be accessed. This indicates a bad spot on the disk. There could also be a problem with the File Allocation Table that the operating system keeps. In the case of status 2 on a write operation, it is possible that your file is fine and you are simply out of disk space. Common Preventable Causes: 1. Overwritten Position Block: Perhaps the most obvious cause for status 2 is an overwritten position block. Check where in the program the position block is defined, and what variables are defined immediately before the position block. See when, where and how these variables are accessed, to make sure the position block is not overwritten. Moreover, be sure that after the OPEN call you do not modify the position block. 2. Multiple Pre-image Files for One Data File Having multiple pre-image files for one data file can definitely cause problems. By default, Btrieve creates the pre-image file in the same directory as the data file. You do want to make sure that all workstations that are accessing the same data file access the same pre-image file. This problem may manifest itself in the form of using NetWare search mappings to find a Btrieve file. When Btrieve opens a file, it expects the complete path\file_name, or just the file_name. Btrieve will go to the path specified to open the Btrieve file, or in the case of just the file name, Btrieve looks in the default directory for the file. In versions prior to 5.0, if Btrieve does not find the data file in the current default directory, NetWare may find the file through one of its search mappings and be able to successfully open the file. This can cause problems since Btrieve does not have a complete path. Specifically, on write operations, the pre-image file that Btrieve uses will be created in the current default directory. If several users are accessing the same data file from different default directories, they could all end up with their own .PRE files. If an operation needed to be rolled back, (flagged by the header page of the data file) the workstation would use the .PRE file it knew about, which more than likely was not the one that needed to be rolled back. Using an old pre-image file would damage a Btrieve file. By the same token, if you are directing your pre-image files, make sure everybody on the network specifies the same destination. Otherwise, you will encounter the problem of multiple pre-image files. You can direct your pre-image files using the /I option at load time. (This feature is not available with NetWare Btrieve and Btrieve for Xenix.) 3. One Pre-image File for Multiple Data Files: On the other hand, having one pre-image file for multiple data files could potentially cause file corruption. Be sure that file names are unique, with different extensions. Since Btrieve uses the .PRE extension for pre-image files, data files such as EMPLOYEE.DAT and EMPLOYEE.VAC have the same pre-image file. 4. Large Pre-image File Inside a Transaction: Status 2 could also be returned on a write operation inside a transaction if you do not have enough disk space for the pre-image file. Inside a begin/end transaction operation, Btrieve appends pages to the pre-image file. Naturally, after many write operations inside a transaction, the pre-image file can become quite large. At this point, if an application receives an error status, most applications trap for errors and try to terminate gracefully, closing all the files along the way. The offending pre-image file is also deleted and the space it occupied is released, making it impossible to detect that shortage of disk space was the culprit. 5. NetWare Flag of Btrieve Files: On NetWare, all Btrieve files are flagged as Non-Shareable, Read/Write as they are created. In all circumstances, you do not want to re-flag Btrieve files as Shareable. Flagging a file Non-Shareable means asking NetWare to pay attention to the open mode of the file. Since different "flavors" of Btrieve open files in different modes, this prevents different "flavors" of Btrieve from opening the same file and updating to it at the same time. In some cases, this would lead to file corruption. For example, if you flag a file as Shareable, and load Btrieve Single-User on two stations. The file is open on both stations and updates are done to it. Since Btrieve Single-User is not aware that the file is being shared with other workstations, it does not test for contentions or apply any locks. It may make inappropriate modifications to the file. 6. User Access Rights: In a network environment, make sure that the user has proper security rights to all files that need to be accessed. On NetWare, if the user is opening the file in normal, accelerated, or exclusive mode, the user must have READ, WRITE and CREATE rights for the directories that contain Btrieve files (including a transaction file, if applicable). 7. Using TTS and Btrieve for DOS 3.1 Networks: Status 2 may also come back with the following combination: multiple stations using Btrieve for DOS 3.1 Networks access the same files on NetWare 2.10 or greater, the Transactional Tracking System feature is activated, and your file is flagged as Transactional. Keep in mind that TTS is locking every page that it accesses. This includes the first page of the file, also known as the header page. If another station tries to access the same file, Btrieve sees that the header page has been locked, but that the lock was not enforced by Btrieve. Btrieve will return status 2. Note that the file is not damaged in any way. When the first station closes the file, the second station will be able to access it. Therefore, when you use Btrieve for DOS 3.1 Networks, you should flag your files as non-transactional and let Btrieve handle file integrity with its pre-imaging. If you are using NetWare Btrieve, then you have the choice of using NetWare's TTS (if available on your version of NetWare) or Btrieve's pre-imaging for file integrity. 8. Using NetWare v2.12, NetWare Btrieve v4.11 and Btrieve Transaction: Last, but not least, if you are using NetWare Btrieve v4.11a on NetWare 2.12, you may receive status 2 inserting records inside a Btrieve transaction. This problem has been addressed in version 5.0 of NetWare Btrieve and NetWare 2.15. The above information was intended to give some additional insights into the difficulty of diagnosing status 2 and some known causes. Since each case may be slightly different, only the most common things have been covered. If you are experiencing status 2 and none of the above seems to apply, please contact Novell DPD technical support.