Hi Jeff. Welcome to the forum!
Is there a particular reason you want to use QR codes? A standard barcode might serve you just as well; barcode scanners are cheep and ubiquitous. It's easy to setup almost any identifier in your db to be used as a barcode. Perhaps you could give us some further information: Are you thinking that you want to look up a specific record? A set of (un)related records?
If you think barcodes might be the answer, there are a number of threads in this forum, along with a vast knowledge base in the FMP community on the many ways to incorporate them into your solution.
We are looking at using the QR Code because of the amount of information that can be contained in the code which leads to greater flexiblity in the field and how it can be used to access the relavent information to be stored in the database is our thought.
Are you thinking QR because you can encode a lot of data, versus barcode which is somewhat limited. Having developed in a production environment for a long time, I can tell you that you can get by with a barcode for, let's say, an order number... then throughout the manufacturing process, as the order goes from station to station, additional related data can be generated and recorded- all associated to the order number alone.
We happen to produce and encode gift and phone cards. We can, using only the order number, reconstruct from data where the job was on any given date, what serial numbers were shipped to what location, what machine encoded, what press printed, who packed it, etc..
At each work station the employee scans the barcode and then proceeds with their duties, and all the data generated is related to the scanned order number. Each job is 'checked in' and 'checked out' of a work station. As Nick said above barcode scanners are cheap and ubiquitous. A barcode font can be obtained for a nominal fee (you will need the font on any work station that prints the barcode).
That is correct. We would like to be able to provide the purchaser of our product the ability to look at drawings, metal quality, etc. through our database in FileMaker.
That could be facilitated with an order or project number of modest length, whereas a QR code holds lots of data and is used for conveying data without access to the data system that created it, such as an entire address on a package and maybe the phone number of the recipient.
Given the information you've supplied, I would recommend barcodes over QR codes; easier and cheaper all around. Additionally, depending on how you setup your barcode, your customer doesn't neccessarily need a reader as many barcode systems can display the underlying data below the barcode, allowing your customer to just type the data.
We would like to be able to provide the purchaser of our product the ability to look at drawings, metal quality, etc. through our database in FileMaker.
If I understand correctly, all they need to get from the product itself is the unique ProductID. This would guide them to the corresponding record (or records) in the database.
Barcodes aside for a moment, how do you intend to provide your purchasers with access to your Filemaker database?
1 of 1 people found this helpful
Looking it up in Wikipedia, a QR code can hold about 4,000 alpha-numeric characters, or about 3,000 bytes of data.
I like your idea of encoding information into a QR code, that could then be read by end users without any connections to your files or the internet. It sounds like the QR option could cover the textual infomation, but wouldn't be capable of holding the graphic info - for that, they would need to link back to your served data either with FMP or a browser.
I've never done it, but if they have FMP available to them, I suspect the QR code could actually be a snapshot link that would take them directly to the specified founds set/layout in FMP. This would be pretty cool.
It's more likely that they'll need to use a browser and access your information over the Web. In this case you could embed the web address in the QR code and scanning it with a QR reader would trigger opening the web address in a browser.
I like the idea of using a QR code for this. A straight bar code will be dependent upon the end user having a reader that "understands" your bar code encoding (3 of 9, and so forth) and also knows what to do with it (i.e. actually open the web page as opposed to simply reading the address).
Could you consider 2 codes? One would hold textual information about the product, and the second take them to the drawings? Or perhaps the textual information could include a URL that would then take them to the web info? I don't know enough about QR readers to be sure about this, but a little testing should reveal the capabilities.
FMP of course can't create the QR code directly, but a quick Google search reveals several methods.
If you get this working, please post back to let us know.
Thank you Bob, you have given me the answer that I thought I should get. I have some testing to do with working with FileMaker Server.
Let's look at your question from a practical perspective. I will tell from our practical experience in our library where staff uses 2-3K of codes and does 10K of barcode scans a year.
(Linear) Barcodes are by way the fastest and easiest to read under various environmental conditions, because it's just one dimension that must be fit by the scanner, and the success of the scan process is pretty robust against small rotations of the scanner versus the axis of the code. If the barcode must be read several times during a process, you shouldn't print them yourselves with a laser printer on paper, because after a few reads the barcode will be worn out because of toner abrasion, and then you will get false reads. Instead, buy barcodes from a professional producer; these are sealed under a non-abrasive plastics surface and can be produced in high quantity for a reasonable prize. We have books that get lent and returned up to 70-80 times until the book gets worn out - the barcodes are still ok. Buy good laser scanners that can can be used contact-less and are fast; wand scanners are not to be recommended because they are slow and if staff holds them the wrong way they get false reads.
According to my observation (e.g. in trains for scanning train tickets, or by my own tries), 2D codes such as QR codes need more time to read, and depending on environment (light conditions, shadow, position (distance and rotation) of scanner), one has to try several times until you get a good scan. It's also more difficult to fit them into the scanning zone. Now just estimate the time your staff will lose and the annoyance they will get and express. As previously said, QR codes are good if you need to encode information that can/must be used outside of your system, and for single usage. Recently, we began to put QR codes (in addition to the barcode) onto our Ex-Libris labels (a label that displays ownership of the book), coding an URL that points to the corresponding e-book or a catalog entry.
RFID would be another technology to consider, however, the technology is still not mature and there are many external factors (such as existence of metallic objects near the RFID tag, electromagnetic environment, nearby RFID tags, and most pronouncedly the position (distance and rotation) of the tag in the magnetic field (i.e. versus the antenna)) that influence heavily the quality and success of the scans. Many Swiss libraries have switched to RFID (because there are a handful of producers in Switzerland promoting the technology), however, a recent study showed that 40% of the libraries are not satisfied with RFID technology - a too high number. Although the tags got quite cheap (about 20 cents/tag), the scanning technology and the software are still quite expensive and may make the main part of the TCO. We have just recently decided not to go with RFID because usage of our books, unreliable technology, the change to e-books (which we estimate to be completed in a few years) do not justify the investment. Also, tests of my colleague in industry showed that if you need to be 100% sure that the tag is read (e.g. for counting objects), RFID is clearly not the technology to go. RFID also failed in tests carried out in general and food stores.
Generally, it's recommended to store only the minimal information on the barcode, 2D code, or RFID tag to be able to process it. The less information you store, the less scan errors you will have.
You have lots of helpful ideas above if you should or should not use a QR Code.
I generate QR codes from Filemaker in my ShiftPoint solution for car sales. The QR code is printed on a window sticker so a customer with a smart phone can scan it. When scanned, the webpage for that vechile is opened. I use the 360 works free plugin to create the QR code. For my use it is a great solution.