Code 128 Violates Enumeration Constraint In Reprint Console
I'm looking for help to troubleshoot an error in Reprint Console:
Bartender Client and Server Version: 10.0 SR4
The Server is 2008 R2 / SQL Server 2008 R2
The Workstation is running Windows 7
Error:
An error occurred during BTXML Script processing: 'Code 128' violates enumeration constraint of 'Text Barcode Picture RFID Line Ellipse Box RichText MagneticStripe'. The attribute 'Type' with value 'Code 128' failed to parse. Line 1, Column 1738:
The label contains 2 Code 128 barcodes. The label printed just fine during the initial printout (data printed successfully with both barcodes); however, it fails in Reprint Console with this error. Additionally, Reprint Console does not show all of the populated data source values; however, they do appear in the extended BTXML included in the error message.
-
It sounds like the recorded data in the system database might be corrupt. Do you get the problem when you try to print newly and recently printed labels from this document? If you recreate a test document with similar Code 128 barcodes, do you again have problems reprinting them? Note, I'm trying to ascertain whether this was a one off corruption of data, a specific document related issue, or a Code 128 related problem. If you try to reprint this via History Explorer do you also get the error? If you attempt the reprint as a different Windows user, and/or a different PC do you again get the same error?
0 -
Thanks Ian. The issue is across multiple of our locations (each site with a different databases). Each site has it's own file being printed; however, the format of the labels are very similar. We can print the format successfully in some locations and others it fails. Yes, the error is the same with different PCs/users and it appears in History Explorer reprint as well. I agree it appears to be corrupt data, I'm just not sure how to determine if a group of clients are writing the data incorrectly and others are writing it correctly. One thing that I know has occurred is we installed 10.1 SR4 on some PCs first, then removed and installed 10.0 SR4 because of a variety of issues found with 10.1 SR4. These all appear to be clients with the issue now. I'm attempting to see if we have any "clean" 10.0 SR4's experiencing the same issues. I don't see any real schema difference between the databases created at 10.0 SR4 or updated to 10.1 SR4 and both clients appear to connect and use the databases fine.
QUESTIONS:
1) Is there a way to remove all remnants of the Bartender client from a workstation (the uninstall appears to leave remnants) so we can ensure a clean installation when back-leveling the client?
2) Is there documentation available on the data written to the database that may allow us to identify what is corrupted (if anything)?
0 -
1. After the uninstall go to the Program Files (Program Files (x86)) folder and delete the residual "Seagull" directory. The same goes for the hidden "ProgramData" folder from the bootable partition's root. Next open up the system registry and wipe away the following keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Seagull Scientific
HKEY_LOCAL_MACHINE\SOFTWARE\Seagull Scientific (on a 32 bit system)
HKEY_CURRENT_USER\Software\Seagull Scientific
2. We don't document the schema of the System Database as we reserve the right to change it between versions. Note to access the database with non-BarTender software we recommend using the API of the SystemDatabase() .NET component. There would have been a change between the BarTender versions, so I imagine the problem is caused by version corruption in affected databases.
0 -
Thank you for your quick response. I ran a test this morning and in the same database that is experiencing issues, I can also get generate a working label (same format) from my PC (which happens to have 10.1 SR4). I will see if I can get a good label at 10.0 SR4 as well (I believe we have that case). If so, then it will change the scope of the issue to be with the workstations themselves that are doing the initial writing of the data (which is what I believe to be the case). I will confirm a 10.0 SR4 writes successfully, then work with them to re-install clients to see what happens.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
4 commentaires