By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,952 Members | 1,707 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,952 IT Pros & Developers. It's quick & easy.

How to store/use info from barcode scan?

P: n/a
Here's the background on my situation. The question follows ---

We have 600 units of mail going from our business to various Post
Offices every morning. Every unit is accompanied by a paper
Verification form which is signed and dated by a postal employee
and returned to our office as proof of delivery.

The Verification contains a 24 character barcode which holds a
non-unique 5 digit postal zip code at pos 5-9, and a unique 10-
digit control number at pos 14-23. The other chars are not
essential. As the units leave our office, we will scan the
Verifications to record the barcode info and a date stamp. When
the drivers return the Verifications the next day, we will scan
them again and date stamp the return.

Any time the barcode is scanned, the onscreen form must display
the 10-digit control number, zip code, and post office
name/address associated with that zip code. Printed reports will
show this info also.

One table (PostalInfo) will contain records with Zip, Name,
Address, City, of 50 or more post offices. This table will change
very little once entered. Another table (ScannedInfo) will
contain the scanned barcode information, 600 new records each
day.

Here's the crux: Should I define fields for zip and control
numbers in ScannedInfo, then associate string functions with them
to parse the data from the barcode field? If so, how does that
data get permanently written to those fields, replacing the
function?

Or can I just store the unparsed barcode string, and parse it as
needed in queries or forms? I think that I need to have the
parsed zip and control numbers stored in their own fields in
ScannedInfo so I can set a relationship to the zip code in the
Postal table, and speed searches and queries. This database will
grow by 3000 records weekly, and at least two months history
needs to be available.

Any suggestions will be read with gratitude by this newbie.
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Ok,
I'm by no means an expert at this but the way I would do this it to
create a query that splits the scanned barcode down into the relevant
lengths you need. Some like this.....

SELECT [verification form].[scanned barcode], Mid([verification
form].[scanned barcode],1,5) AS zip, Mid([verification form].[scanned
barcode],6,10) AS [Unique number], Mid([verification form].[scanned
barcode],17,3) AS [extra numbers]
FROM [verification form];

Save that query whose sole function is to split the scanned code into useful
bit of data.
Create another table which will hold the scanned barcode number and then the
other fields that you want to split the barcode into e.g., zip, unique
number etc. Then run an append query which will put all the data (that
doesn't exist already) from the query into the new table. Something like
this would work.....

INSERT INTO [split barcode] ( [scanned barcode], zip, [Unique number],
[extra numbers] )
SELECT [decode barcode].[scanned barcode], [decode barcode].zip, [decode
barcode].[Unique number], [decode barcode].[extra numbers]
FROM [decode barcode] LEFT JOIN [split barcode] ON [decode barcode].[scanned
barcode] = [split barcode].[scanned barcode]
WHERE ((([split barcode].[scanned barcode]) Is Null));

As the entire barcode number is being imported to the new table, that could
act as a link to the new table of split data for any queries you need.

Like I said, I'm no expert but that's the way I would go about it!!! ;-)

Mark

"Tom Turner" <me*@privacy.net> wrote in message
news:Xn*************************@216.196.97.133...
Here's the background on my situation. The question follows ---

We have 600 units of mail going from our business to various Post
Offices every morning. Every unit is accompanied by a paper
Verification form which is signed and dated by a postal employee
and returned to our office as proof of delivery.

The Verification contains a 24 character barcode which holds a
non-unique 5 digit postal zip code at pos 5-9, and a unique 10-
digit control number at pos 14-23. The other chars are not
essential. As the units leave our office, we will scan the
Verifications to record the barcode info and a date stamp. When
the drivers return the Verifications the next day, we will scan
them again and date stamp the return.

Any time the barcode is scanned, the onscreen form must display
the 10-digit control number, zip code, and post office
name/address associated with that zip code. Printed reports will
show this info also.

One table (PostalInfo) will contain records with Zip, Name,
Address, City, of 50 or more post offices. This table will change
very little once entered. Another table (ScannedInfo) will
contain the scanned barcode information, 600 new records each
day.

Here's the crux: Should I define fields for zip and control
numbers in ScannedInfo, then associate string functions with them
to parse the data from the barcode field? If so, how does that
data get permanently written to those fields, replacing the
function?

Or can I just store the unparsed barcode string, and parse it as
needed in queries or forms? I think that I need to have the
parsed zip and control numbers stored in their own fields in
ScannedInfo so I can set a relationship to the zip code in the
Postal table, and speed searches and queries. This database will
grow by 3000 records weekly, and at least two months history
needs to be available.

Any suggestions will be read with gratitude by this newbie.

Nov 12 '05 #2

P: n/a
Pachydermitis typed

Access can't handle this kind of application.


Now, why not?

--
Bas Cost Budde

Nov 12 '05 #3

P: n/a
Mark-

I like your idea of populating a separate table with information
queried from the barcode table. I'm going to pursue it and see what
happens.

Thanks for your time and suggestion.

-Tom

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.