Cannot update the cursor BCTOPRNT since it is read only




Cannot update the cursor BCTOPRNT since it is read only

Affected Users:

LIMS Administrators, Property Evidence Custodians, Lab Analysts who create new cases.

Fielded Statements:

I am unable to print a second barcode label for second piece of evidence entered on a case still in TMP status.

I received the following message when attempting to print a barcode for a second piece of evidence on a new case: “111 Cannot update the cursor BCTOPRNT since it is read only”

I received the following message when attempting to add evidence to a new case: “Fatal error 9 - Data type mismatch”

I am unable to print barcode labels for additional evidence items entered on a new case.


The BCTOPRNT file holds the barcodes about to be sent to the barcode printer. This file resides in the user's temp directory and is updated for each new barcode to be printed. If the file becomes read-only, it cannot be updated for the next barcode label and the 111 error occurs.

Root Cause:

Windows level file permissions granted to users for the user’s local temp directory. This applies to users accessing the LIMS application within a client/server or terminal service environment.


Hank Runkle is a property evidence technician at the Seymour County Crime Laboratory. He begins working inbound evidence that was received in the vault. The case involves a drug offense and there are two bags of evidence that were submitted for controlled substance analysis. He starts a new case and begins entering the evidence information. He is printing barcode evidence labels each of the two bags. He receives the following message when attempting to save the second bag item:


After a few attempts and the same results, Hank asks his colleague Marie to enter in the second bag for him. Before entering the evidence, Marie asks Hank to save the case first so that a Lab case number is assigned. Marie access the lab case number and is able to enter the bag without any issues. Hank continues logging new cases and receives the same message again. He notices that the same behavior is occurring on his machine but not on Marie’s. He contacts the LIMS Administrator to report the error.

John (LIMS administrator) arrives at Hank’s machine and asks Hank to replicate the behavior. John notices that there are actually two messages appearing. The BCTOPRNT error is accompanied by a message “Fatal error 9 - Data type mismatch”.


Unfamiliar with this message, John contacts JusticeTrax Support for assistance.


The scenario listed below involves several components but the errors received are both coming from the same root origin. In order to print barcode labels within the LIMS-plus 3.x application, the code references a dbf file that is located in a user’s local temp directory. The name of the file is BCTOPRNT.dbf. This file stores information that is to be sent to a barcode printer. When this file becomes corrupted or has a file attribute setting of “Read-Only”, the application will return the BCTOPRNT error message when attempting to print the save barcode label information for the second piece of evidence. In the scenario presented, Hank was receiving the error message while Marie was not. In most circumstances, users within the same department will have the same windows permissions applied to their accounts. LIMS-plus simply users the existing windows file permissions granted to a user. The application strictly uses exiting windows file/share permissions granted to the user when it writes information to the a user’s local temporary directory. If a user does not have access to their local temporary directory, this error message can occur.

One way to avoid this message is to save a case as soon as possible. Historically, this error occurs in higher frequency when a case is in TMP status. In the scenario presented, the case was saved prior to Marie entering the second bag of evidence. Marie was accessing the case after it had moved from TMP status to one where a Lab case number was assigned. Furthermore, Marie’s user profile had different file permissions granted to her with respect to the local temp directory.

Terminal Server environments are also unique in that the terminal server itself holds the user profiles for connections made to it. TS users may not have access to the local temp directory on the server itself. It is highly advised that Terminal Server are configured so that files written to the local temp directory can be modified as well.

The fastest solution to this error would be to delete the BCTOPRNT.dbf. Deleting the BCTOPRNT.dbf from the affected user’s local temp directory will correct this problem. However, the local temp directory should not be configured as read-only. Laboratories that choose to use a terminal server connection environment should make sure that the temp directories for user accounts are configured so that read/write access is granted to these directories. The BCTOPRNT.dbf is created when the application is initially launched.

The local temp directory for user profiles are typically stored in the following locations:

For a Windows XP user: C:\Documents and Settings\USERNAME\Local Settings\Temp\

For a Windows Vista user: C:\Users\USERNAME\AppData\Local\Temp\

The easiest way to navigate to the local temp directory is to do the following:

While logged into a workstation using the affected NT login account:

Start>>Run>type "%temp%" without quotation marks.

Example listed below:


The BCTOPRNT.dbf cannot be deleted until after the LIMS-plus application has been closed.




Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk