Driver S License Pdf417 Barcode Application

Ever wonder what's in that barcode on the back of your driver's license? I just got a new toy that I'm playing around with, and I'd like to incorporate A5 to allow me to use it for something useful. It's a Handheld 2D Barcode Scanner, and I want to use it to scan the barcode on the back of a driver's license, then populate forms with the resulting data. I'm using a special 'sample' Maryland driver's license for testing, but it conforms to the AAMVA standards for universal license data coding. (In other words, it should pretty much work the same way on a license from any state using the AAMVA format.) So what's in the that funny looking barcode?

Barcode Interpretation Information. The South Carolina DMV driver license and identification cards contain a. PDF417 two-dimensional (2-D) barcode on the reverse of all cards. This barcode contains the same text information contained on the front of the card and is useful for performing functions such as electronic age. Driver License scanning - Barcode scanning for PDF417 is no longer working for some states #231. Kkamaraj opened this Issue on May 31 13 comments.

Rich, For this application, it looks like the best approach would be to scan it into a text area, then parse it with extract_string(). So, for example, if the bar code was read into a variable named BarCodeText, you could have: vAddress = extract_string(BarCodeText,'DAG','DAI') Then, as Mauricio suggested, for the name, you could use the word() to break that up The only issue I see is if the street name is Adai street, or if the person is named Dagwood. To handle that, you could use the occurs() function to check how may times it appears. So if 'DAG' appears twice, then you know there could be a problem. Hi Rich, Parsing a barcode, yours included, is relatively trivial. There are a myriad of character parsing functions that are usable in Alpha, and there is nothing special here.

The real issue, is that a barcode scanner will scan the data into where ever the cursor is. If the cursor is not where you need data, the barcode characters will be entered wherever it is. If you could get the cursor to move to a particular field or dialog box 1st, then the data entered can be used to fill in data or invoke a find, or whatever you needed to be done.

This is exactly what my does for the desktop side. (which incidently the trial version has a working function feature that has a test mode that allows you to see all characters that the scanner sends, even special keys) within Alpha Five. Doing it for the web side requires handling a javascript key event, which Alpha does not have. It could be done, but each of the 5 most common browsers all handle key events differently (some in major ways, some minor). Unfortunately, there is no current web standard for key events (unfortunately).

If one chooses a specific browser, then it is much simpler problem. Well thanks to the input from everyone, I'm getting closer.

I'm trying Pat's suggestion of the 'exact_string' expression, and it seems to parse all of the fields correctly, but I'm running into a weird problem that I'm hoping someone might have an answer to. One of the parsed fields is called 'DBB_DOB,' and it results in a character string date of the person's date of birth. Korg Triton Rhodes Patch here. Next to it, I created another field called 'DOB,' and I'm using the below expression to convert the string to a 'normal' type date: DATE_VALUE(VAL(LEFT(DBB_DOB,4)),VAL(SUBSTR(DBB_DOB,5,2)),VAL(SUBSTR(DBB_DOB,7,2))) Again, it works correctly, and the DBB_DOB string of 19560115 converts correctly to, but when I try to start a new record, I immediately get an error message that says: 'MONTH IS OUT OF RANGE.' Then if I try to close out of the table or delete that record, I get another message that says 'ENTER MUST BEGIN FIRST.' And then I'm stuck, because it won't go past that point.

When that happens, the only way to get out of the table is to forcibly close out of the program. The expression to convert the date seems to be working correctly, so I don't know why it keeps saying that the month is out of range, but if I get rid of the expression, the errors go away. Richard EDIT: I see you got it working already. Strange that stod() is not throwing an error for you.

When you start a new record the DBB_DOB field is empty. This results in zeros being passed into the Date_Value function.

I was going to suggest the STOD() function instead but it to throws an error with an empty string and also with a string of 10 spaces. Instead of having two fields I would have only the date type. Convert the barcode text data to a date using stod() as part of your parsing process.

That way the actual DOB field does not need to be any type of calculation. Hi Tim, Well I think the problem was related more to the character date field than to the expression.

I thought that using STOD() had solved the problem, but as it turns out, it didn't, it just made for a shorter, neater expression. This is how I fixed it, although I'm not quite sure what the cause was. My character date field has an expression that parses the date from the long barcode string: EXTRACT_STRING(MEMO,'DBB','DB') Which results in (for example) 19840117 in a field called 'DBB_DOB' Whenever I try to convert that field to a date field by either my original expression or the STOD(DBB_DOB) expression, I get the 'Month is out of range' error message when I try to exit the table. So as a test, I created a second character date field, and used the simple expression (DBB_DOB) to copy the contents of the first character date field into this one, and called it 'DBB_DOB2.' Then I used the STOD(DBB_DOB2) to convert that field's contents to an actual date (), and it works with no errors. Now you are suggesting that I go directly from the long barcode string to the actual date field, but I'm not sure how to do that, or how the expression will know where to find the character date, but maybe you can elaborate. I do know it's between DBB and DBC in the original barcode text string if that helps.

Macromedia Flash 8 Mini Projects Free Download here. So now that I know all this, I'm looking for a simple (if possible) way to scan it to a field on a web page, then upon clicking submit, having the data parsed correctly into separate fields for use on that particular web form.Are you still doing that. Can you elaborate a bit on your process. I am guessing you are scanning into a memo field???

Then what is your parsing process. Is it a script of some sort or are you using calculated fields? If I was doing this on the desktop I would have a script that takes the whole set of data and for each field I want to fill find the data and convert it into the data type of that field. Tim I haven't got it working on the web yet, right now I'm just trying to get all the parsing correct. And yes, at the moment I am just scanning the long text string into a memo field, and using the 'extract_string(BarCodeText,'XXX','XXX')' expression in each of the parsed fields to pull the correct data, and that seems to be working just fine.

My original goal was to have a separate web screen (maybe a popup) just for scanning the data into, then when the submit button was pressed, it would parse the data into the correct fields (on the back end), which could then be pulled into any form that had the need for that data. It would be nice to be able to skip the first part of this and have the data go directly into the form that requires it, but since everything I'm doing is web based, I don't see an easy way to accomplish that. Ira has a neat barcode program for desktop applications, but he said it would be somewhat complicated to do in a web browser, since it would vary depending on which browser the client was using. Tim here's what I'm doing: I have a memo field that takes the following barcode data, and parses it out using calculated fields - AAMVADL00290197DLDAQS-542-738-870-099 DAASMITH,RICHARD,JOHN,JR DAG26 SAMANTHA CT DAITAKOMA PARK DAJMD DAK20912 DARC DAS DAT DAU600 DAW167 DBA20110124 DBB19820124 DBC1 DBD20051126 DBHN Each field is delimited by the first three charcters. The 'DBB' string is the person's DOB, which in this case is. Presently I'm using the following expression to parse out the date string: EXTRACT_STRING(MEMO,'DBB','DB') This gives me '19820124' as a character field, which I call 'DBB_DOB.'

Then I was using a separate (date) field to convert the character string to the actual date: STOD(DBB_DOB) = This works as I said earlier, but as soon as I try to enter a new record, I get an error message because as you said, the character string for the date field hasn't been created yet, and as such it throws the record into a crazy loop which gives an error message of 'MONTH IS OUT OF RANGE,' then 'ENTER MUST BEGIN FIRST,' and stays the way until I force the program to close. Now you suggested that I parse out the character date string and convert it to a regular date all at one time, but I'm not sure what the expression would look like to do that. Could you show me how? Everything else about this application is working correctly except for this date issue, so if I can get this working I'll be finished. Stan thanks for replying so fast, but I'm not really sure what you are telling me? I'm familiar with the STOD() function, and as listed above, I am using it to convert my parsed character string into an actual date.

The problem is that it is causing errors at the end of the record, and Tim was suggesting that I parse the character string from the barcode data AND convert it to an actual date all at one time, but I don't understand how to do that. That's what I'm looking for assistance with. I assume it would be some sort of a nested expression, but I've been playing around with it for hours and I can't figure out how to make it work. Hi Tim Your expression works correctly, however now another weird thing is happening. If I enter the barcode scan data directly into record via browse, the DOB calculation works fine. But if I enter it via the web page, as soon as I hit the submit button, I get an error message on the DOB field, that says 'CAN'T PUT TO CALCULATED FIELD.' Any thoughts?

BTW, here's the link to the form: If you want to see what I'm getting, manually paste the following data into the memo field and hit the submit button: AAMVADL00290197DLDAQS-542-738-870-099 DAASMITH,RICHARD,WELLINGTON,JR DAG26 SAUCER CT DAITAKOMA PARK DAJMD DAK20912 DARC DAS DAT DAU600 DAW167 DBA20110124 DBB19820124 DBC1 DBD20051126 DBHN. Hi Tim Your expression works correctly, however now another weird thing is happening. If I enter the barcode scan data directly into record via browse, the DOB calculation works fine. But if I enter it via the web page, as soon as I hit the submit button, I get an error message on the DOB field, that says 'CAN'T PUT TO CALCULATED FIELD.' Hey Tim just wanted to let you know that your expression is working perfectly.

I don't know what was causing the above error message, but I fixed it by rebuilding the grid. I have another question regarding parsing that I was hoping someone could shed some light on. Sample barcode extract into memo field: AAMVADL00290197DLDAQS-542-738-870-099 DAASMITH,RICHARD,WELLINGTON,JR DAG 26 SAUCER CT DAITAKOMA PARK DAJMD DAK20912 DARC DAS DAT DAU600 DAW167 DBA20110124 DBB19820124 DBC1 DBD20051126 DBHN Presently I'm using the expression of (for example): EXTRACT_STRING(MEMO,'DAG','DAI') to parse the address from the memo field and similar expressions to parse the other data. This works fine as long as the next field starts with the delimiter of 'DAI,' which it always does in Maryland.

But I just found out that other states layout their data differently. They still use the same delimiters, as that is based on a national standard, but the data doesn't always flow the same way. For example, in one state, the address field is followed by the Organ Donor field. The delimiter for the Organ Donor field is DBH. Obviously this causes a problem with the 'Exact String' expression because it is looking for DAI as the end point, now it does not follow DAG. So my question is this: There is a set maximum number of characters that can be used in each field, so that will never change and that being the case, is there a similar expression I could use that would still parse the data from the set delimiters of 'DAG,' 'DAS,' etc., but instead of using the next text delimiter to indicate the end of the parse, it would only parse the string up to the maximum number of allowable charcters, then stop. In other words, something like: EXTRACT_STRING(MEMO,'DAG',30) or something like that, so that once a space of 30 characters was reached, the expression would know it was the end of the string.

(I know this is not a real expression, but in looking at it you can get the drift of what I'm trying to do.). It looks like Post #20.

The first one was 'doctored up' by me to show everybody what data is embedded in the barcode. However my barcode scanner is stripping out the carriage return symbol and entering straight text. This was done on purpose. When I first started this project, every time I would input data on to the memo field of the web page, the browser screen would go crazy and try to open up all kinds of browser related options. In the end, the only thing that was left in the memo field was the '@' symbol.

To to counter that, the tech from the barcode reader company set the gun so that it stripped out everything but straight text, and the problem disappeared. And I think I know where you're going with this. Are you going to suggest using the carriage return as the ending delimiter? I thought about that. I'm not sure how the expression reads, but I guess I'll have to put the carriage returns back in the bar code reader's output first if I'm going to experiment with that.

We didn't determine that the problem was the carriage returns, as there are other symbols inserted during the initial data input that could have been causing the problem, but the tech suggested just getting rid of all the non-text characters and trying it. That's what we did and it solved the problem so I just left it that way. So maybe if I put the carriage returns back in and nothing else, I'll be able to have it 'both ways.' Not sure Tim, but I'm waiting for a return call from the tech at OptiCon, and I'll check with him to see if that can be done. Meanwhile, here's what the barcode scanner output looked like before we removed all the invisible characters: @ AAMVADL00290197DLDAQS-542-738-870-065DAASAMUELS,RICHARD,WELLINGTON,JRDAG26 SEEK CTDAITAKOMA PARKDAJMDDAK20912 DARC DAS DAT DAU600DAW167DBA20110124DBB19820124DBC1DBD20051126DBHN I'm not sure what was causing all the browser problems, but I guess I could play with some different things. Very interesting Mike.

Unfortunately in my situation things have changed a bit. We are now using an electronic traffic citation program provided by the state, and it has a 2D barcode reader attached to it already. This is both good and bad for my purposes.

On one hand the state has taken care of my problem of getting the driver's license data parsed and inserted into the correct fields on THEIR form, but it doesn't allow me to use that data for anything else, like my web based records application. In this case, the scanner (L-Tron/Honeywell model) is plugged into usb and grabs a port in the computer. The state's software then talks to that port and tells the scanner when to turn on and when to turn off. It also takes the data and forces it directly into their program, then closes the scanner application. According to L-Tron, it would be very complicated to try to re-route that port's data to another application, then switch it back again on the fly, but I am still playing with it so we'll see what happens.

It seems like such a waste to have a $500 barcode scanner sitting in the police car and only be able to use it on one application, and not on the multitude of other forms that we need DL data from.

The DL/ID parser is fairly simple and doesn't work perfectly on IDs from all states, unfortunately. There might be some jurisdiction-specific fields that are tripping it up, or they might not be using a fully spec-compliant encoding. We'd like to improve it -- if you'd like to help, the anonymized raw text of the non-working cards would be helpful in diagnosing the problem. However, if you aren't comfortable sharing it (or just aren't sure how to completely remove all identifying information) that's okay too! Sure, here is the raw data from the scanner. I used the sample license from internet for FL state.

Actually, please disregard the earlier sample I posted; I'm not sure why, but escaping the string correctly and dumping it on a single line made the prefices and suffices I was expecting show up. These samples are also from Oregon and don't register as driver's licenses, even though they do have the @ n rANSI prefix. They're malformed in other ways, of course. Ah, my mistake. These should match the original byte positions: @ nN rANSI DL00390285ZO03240027DLDAQ1234567 nDAALASTN, FIRST MIDDLE nDAG nDAL5555 NE NNTH AVE nDAIPORTLAND nDAJOR nDAK97215 nDARC I nDASBD nDAT nDAU009 nDAW135 nDBAYYYYMMDD nDBBYYYYMMDD nDBC1 nDBDYYYYMMDD n rZOZOAFIRST LICENSED YYYYMMDD r @ n� rANSI DL00390192ZO02310031DLDAQ1234567 nDAALASTN, FIRST MIDDLE nDAG nDAL55555 NE ANOTHER DR APT 101 nDAIBEAVERTON nDAJOR nDAK97006 nDARC nDASBD nDAT nDAU509 nDAW135 nDBAYYYYMMDD nDBBYYYYMMDD nDBC1 nDBDYYYYMMDD nZOZOAFIRST LICENSED MM-DD-YYYY n.