Automation

  • Thread starter Thread starter cgreen
  • Start date Start date
C

cgreen

Hi Folks,

Need help AUTOMATING the process of importing a text document into Access in
which the data has been uploaded from a hand held scanner.

Any thoughs/comments, E-me

Thanks in advance.
 
cgreen said:
Hi Folks,

Need help AUTOMATING the process of importing a text document into Access in
which the data has been uploaded from a hand held scanner.

Any thoughs/comments, E-me

Thanks in advance.

The solving of your problem must not be very important to you since your
definition of the problem is so poor. Maybe someone in the many
newsgroups you cross-posted to can help decipher your obtuseness.
 
GEESH!! If you wanted clarification you could've just asked! ;-)

For those of you who didn't understand me the first time, the device we use
is
a bar-code scanner -- much like what you see in super markets.
For our purpose, it's used for scanning serial numbers.
Once the scanning process has completed the data/serial numbers must be
uploaded
(utilizing serial cables) to the PC to a .txt file (NotePad...). and then
the .txt file
is saved under a naming convention.

From there, these serial numbers are manually entered into our Access
database. The problem
is that the data entry people have been known to make mistakes. So, by
automating everything,
I believe, we should encounter fewer mistakes.

....can anybody help?
 
cgreen said:
GEESH!! If you wanted clarification you could've just asked! ;-)

For those of you who didn't understand me the first time, the device we use
is
a bar-code scanner -- much like what you see in super markets.
For our purpose, it's used for scanning serial numbers.
Once the scanning process has completed the data/serial numbers must be
uploaded
(utilizing serial cables) to the PC to a .txt file (NotePad...). and then
the .txt file
is saved under a naming convention.

From there, these serial numbers are manually entered into our Access
database. The problem
is that the data entry people have been known to make mistakes. So, by
automating everything,
I believe, we should encounter fewer mistakes.

...can anybody help?

If you use a scanner that connects with a keyboard wedge it is then easy to scan
directly into Access. Is that an option for you?
 
cgreen said:
GEESH!! If you wanted clarification you could've just asked! ;-)

For those of you who didn't understand me the first time, the device we use
is
a bar-code scanner -- much like what you see in super markets.
For our purpose, it's used for scanning serial numbers.
Once the scanning process has completed the data/serial numbers must be
uploaded
(utilizing serial cables) to the PC to a .txt file (NotePad...). and then
the .txt file
is saved under a naming convention.

From there, these serial numbers are manually entered into our Access
database. The problem
is that the data entry people have been known to make mistakes. So, by
automating everything,
I believe, we should encounter fewer mistakes.

...can anybody help?

OK. If you have the data in a standard format in a file that the program
can find then you have a fighting chance of being able to upload the
data automatically.

There are two things that are important. One is the name of the file and
the other is the format of the data in it.

If the format of the data is suitable and it always has the same name
then you could use it as external data in a linked table.

If the name changes but the format is tabular then you could use the VBA
DoCmd.TransferText command to upload the data into an Access table then
process it.

If the format is not tabular then you could either use an external
program (such as awk) to reformat the data. Alternatively you can write
VBA code to read characters from the file and process them.

Lastly, as someone else suggested, you could choose a scanner that
emulates a keyboard. That way your users could input the data directly
into an Access form.

If you have any doubts then post a copy of the data file to
comp.databases.ms-access and I'll take a look at it. But I strongly
suggest that you trim the crossposting. There are people who might be
able to help you but won't even see your message because they
automatically kill multiply crossposted messages.
 
Two options - if your app exports or saves to a standard format that
Access can read, then dump it into a directory and let Access do the
importing. Just create an import spec. If that wont work because the
data is weird, you'll have to open the file in code and parse it.

And NO, puh-leeze! Do NOT post your binaries here. If you have to
post SOME of the import file, then post like 3 lines from your file,
not the whole thing. Just enough to give everyone an idea of what it
looks like. As my English prof said to me once "Make a case, not a
collage!"

Thanks
 
Rick said:
If you use a scanner that connects with a keyboard wedge it is then easy to scan
directly into Access. Is that an option for you?

I've not used a kb wedge myseld but I see a potential problem in doing
so, it's almost as bad as using SendKeys. It's OK when the program
accepting the keystrokes behaves as expected but if something goes wrong
you will get unexpected results at best, worse than that is if the
program loses focus and the keystrokes are sent to another part of the
application or to another application.

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\
 
Trevor Best said:
I've not used a kb wedge myseld but I see a potential problem in doing
so, it's almost as bad as using SendKeys. It's OK when the program
accepting the keystrokes behaves as expected but if something goes wrong
you will get unexpected results at best, worse than that is if the
program loses focus and the keystrokes are sent to another part of the
application or to another application.

<shrug> Yeah but ... <smile> Sendkeys do things such as enter or other
wierdness. Hopefully if you are doing some bar code scanning you can redo it if
something pops up.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
cgreen said:
For those of you who didn't understand me the first time, the device we use
is
a bar-code scanner -- much like what you see in super markets.
For our purpose, it's used for scanning serial numbers.
Once the scanning process has completed the data/serial numbers must be
uploaded
(utilizing serial cables) to the PC to a .txt file (NotePad...). and then
the .txt file
is saved under a naming convention.

Why not use a scanner hooked directly to the PC rather than a handheld device? I do
realize that there may very well be very valid reasons but thought I'd ask anyhow.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Tony said:
Why not use a scanner hooked directly to the PC rather than a handheld device? I do
realize that there may very well be very valid reasons but thought I'd ask anyhow.

In an application where I used a barcode scanner, it was a goods inwards
depot, the delivered boxes were a bit big for bringing into the office
near enough to the PC, although I know now there is a radio option for
it so it would work like a handheld but be connected directly to the PC.

--

\\\\\\
\\ \\ Windows is searching
\ \ For your sig.
\ \ Please Wait.
\__\
 
Hi ALL, and you too Trevor,

Thanks for the suggestions...they were plenty helpful!

To answer your question Trevor, the scanner is portable because
it is often used offsite.
 
Hi Rick,

Fortunately, we don't need a wedge...that's sounds funny!
Seriously though, the data (when imported/uploaded)
comes out exactly how we want to view it.
(In other words, no decoding is required).

Thanks again.....
 
If the handheld device acts as a removable hard drive, drag and drop
can be really easy for the end user. Just drag the file onto your
waiting form, then you can set it to save the source file to a backup
location, then perform all your validation and parsing. Try searching
for "Stephen Lebans cdrag dll".

If the device just uploads text as if it were typed all at once, why
not use an unbound text box in a form instead of entering into
notepad? Have the user click one button to get ready for the upload,
then another after it's done so the processing can begin.

The only problem I have with not scanning directly to the database is
that it somewhat complicates dealing with how barcode scanners
occasionally read a digit wrong. Instead of just making the user
rescan one item, they may have to scan the batch again.
 
cgreen said:
Hi Rick,

Fortunately, we don't need a wedge...that's sounds funny!
Seriously though, the data (when imported/uploaded)
comes out exactly how we want to view it.
(In other words, no decoding is required).

My suggestion had nothing to do with decoding. Using a keyboard wedge scanner
the values would go straight into Access eliminating the manual entry step you
mentioned. If you sometimes use the scanner off-site then this would not be an
option, but otherwise it would be much simpler.
 
Salad said:
The solving of your problem must not be very important to you since your
definition of the problem is so poor. Maybe someone in the many
newsgroups you cross-posted to can help decipher your obtuseness.
 
Two options - if your app exports or saves to a standard format that
Access can read, then dump it into a directory and let Access do the
importing. Just create an import spec. If that wont work because the
data is weird, you'll have to open the file in code and parse it.

And NO, puh-leeze! Do NOT post your binaries here. If you have to
post SOME of the import file, then post like 3 lines from your file,
not the whole thing. Just enough to give everyone an idea of what it
looks like. As my English prof said to me once "Make a case, not a
collage!"

Thanks

If you need to post a *little bit* of the textfile you get from the
barcode reader, post just enough for everyone to get an idea of what
you're dealing with. Most of the time, it's less than ten lines or
so. If you give us that much, someone can tell you how to go about
processing the data. My bet is that you can probably use an import
specification when you do DoCmd.TransferText... check the help on that
and post back if you still have problems.
 
Back
Top