Month: January 2017

Producing barcode labels requires a numbers of different hardware and software components. There are many different combinations of these which may work for different setups, but here is what is working for us.

*  *  *

First, we had to consider how we would be generating the labels. We already use Crystal Reports to connect to our database and produce reports, and luckily Crystal Reports is able to generate dynamic barcodes both out-of-the-box and with purchased add-ons. While it is possible to invest in other barcoding software to do the trick (such as a standalone barcode label program like BarTender), it made more sense (and cost less money) to try and incorporate barcodes into our already-existing system of Crystal Reports labels and printouts.

Next, we needed to be able to encode the relevant information into a barcode that the scanner would read—for us, that means we will need to encode the accession number for each object barcode and a number randomly assigned to each location record by our database (the key field) for every location barcode.

We chose to use a 1D barcode style; these are the standard linear barcodes you might see on a box of cereal at the grocery store. There are also 2D barcodes—these are the small, square-shaped barcodes that have become more popular in recent years to encode large amounts of information, typically seen in advertising. As 2D barcodes tend to be more difficult for a barcode scanner to read, and the information needing to be encoded is reasonably simple, we decided to stick with the 1D barcode option.

There are a great number of 1D barcode symbologies (think of them as different barcode alphabets), but we initially settled on Code 39 as it is commonly used and generally easy for barcode scanners to read because it only encodes the Roman alphabet (no distinction between upper and lowercase letters), numbers, and a handful of special characters. Unfortunately, we quickly realized during our testing phase that a Code 39 symbology was unable to properly encode even our relatively simple accession number system, and that even when it did work, the barcodes were sometimes exceptionally long. We then decided to try Code 128 barcodes, which allow for much greater range of special characters to be encoded into the barcode. We have been using it so far and it seems to work just fine for us.

We researched two ways to create dynamic barcodes in Crystal Reports: one is to use a barcode font in conjunction with a formula within the program, and the other is to use only a formula that produces barcode images within the report. We learned that the out-of-the-box barcode font that comes with Crystal Reports was not complex enough to encode our accession numbers. We then downloaded the demo version of the BarcodeWiz barcode font software that gives you a number of Code 39 and Code 128 barcode styles to choose from as well as the formulas necessary to produce them in Crystal Reports. For comparison, the demo version of the IDAutomation Native Linear Barcode Generator for Crystal Reports was also downloaded for testing, which is the style of software that generates an image of a barcode with a formula.

Both have their advantages and drawbacks. The BarcodeWiz barcode fonts have good readability with the scanner, but we discovered that there is a problem with the Crystal Reports Viewer that will not allow these barcodes to display when generated on remote computers—so, the computers in museum collections around campus would not necessarily be able to generate them.  The barcode images made with the IDAutomation software will generate successfully on remote computers, but there are some reported issues with their readability when printed with thermal printing technology.

In the end, we have resolved to purchase both and use either method where appropriate. It should not make any difference in how the scanner reads each barcode, and will allow us to overcome the disadvantages of either method.


Part of what makes the Axiell Move app so useful for the museum collections here on campus is its integration with Containers Authority in the Mimsy database—that is, its ability to recognize different containers and use them to update the location for multiple objects at once.

Containers (for example, crates used for shipping or solander boxes) will be given their own ID number and corresponding barcode, and any objects scanned into the container with the Axiell Move app and barcode scanner will inherit its location. The container can then be moved to a new location and all the objects both physically and virtually within it will inherit these location changes within the database. This has time-saving implications for shipping, loans, and moving objects for an exhibition.

While this functionality has existed within the database for some time, it has not yet been implemented in any of the collections. By assigning numbers to our existing boxes, crates, and other containers as part of this location tracking project, we will be able to process large moves in the database quickly and efficiently. Work is already underway to create these container records in the Art database.

As previously mentioned on this blog, this is a pilot project that we hope to extend to other collections on campus upon its completion. To complement the data work that has been carried out so far, an assessment of all the collections currently in the Mimsy XG database was undertaken to determine the work that would need to be done before they were ready for the Axiell Move app. We reviewed and compiled information on:

  • Record linking—were objects with multiple parts/records correctly designated as such and linked to each other?
  • Location records—were they correct and up to date?
  • Accession numbers—would any pose challenges when being encoded in a barcode (e.g. length, special characters)?
  • Containers Authority—was it set up for the specific collection?
  • What kinds of moves were currently being tracked within the database (e.g. loans)?

This review is crucial for the long-term success of our barcoding as it will allow us to present a setup and implementation plan to future adopters of this system, and take out any of the guesswork for collections staff.