Scanning Documents Electronically 2

[FoxAl]

I am investigating how to Scan Documents Electronically into a Foxpro (DOS) Application rather than have the users input the data manually.

If possible, a few queries arise:-

1. How do I set up procedure for such.
2. How do I access an update table from results scanned
3. Error Routines.
4. 3rd Party Products needed.
5. Cost?

Any info or references to web sites would be most appreciated.

Thanks

 

[rgbean]

I believe there are a number of threads on this topic in the VFP Forum - of course they do require using VFP. Is there really any reason to add new functionality to an application developed in an obsolete/unsupported product?

While I still occasionally have to support a FPD app, I make it clear that it's strictly for fixing problems - never to add new features.

Rick

 

[DSummZZZ]

You may get some more answers on scanning in the ScanSoft: OmniForm forum:
forum939 here are some basics I remember from when I was attempting this a few years back.

1. How do I set up procedure for such.
You probably won't be able to control it directly from FoxPro. VFP with an ActiveX compnent or ocx probably would be doable. Otherwise, it will take running a 3rd party package to scan documents and output the result to a flat text file or an ODBC connection. At the time, I was using an OmniForm demo which scanned the docs and appended the records to an MS-SQL database via ODBC.
2. How do I access an update table from results scanned
There were limited number of formats OCR (Optical Character Recognition) software would use. Flat text, proprietary tables, some ODBC connections. Now this was about 5 years ago so there may be a few 'more compatible' packages out there now.
3. Error Routines.
Even when scanning batches of forms, tens at a time as opposed to an occasional one, you still need to have a person verifying the scanned fields. These are areas you designate on a form template (click and drag) for each type of form you want to scan. After scanning a doc, a user tabs through each field and verifies that the data on the form matches what that the OCR software interpreted it to be. Especially with handwritten forms. These can be separated into different 'piles' depending on the data validity i.e., good (100% complete and read perfectly), bad (missing data or bad read which requires editing) or unreadable/rejected. I put this in 'error routines' because this is done by the user, not a Fox routine. Data update error handling would be done by the 3rd party package and not by Fox.
4. 3rd Party Products needed.
You will need some sort of OCR software that can not only trigger the scanner, but can read the forms as I mentioned previously. Do a Google on OCR or scanning and you will get a bunch of hits. LeadTools is a VFP compatible package I tested once. Be prepared to spend a lot of money per workstation though.
5. Cost?
As I said, be prepared to spend a lot of money. The three main factors are:
1- How many workstations will be "scan" stations versus QA stations. You will sometimes need separate licenses for scan stations (more money) than you will need for QA stations. You may have only 1 or 2 scanners, but depending on how many forms you scan and how fast they scan, you may have 5+ people QAing those forms.
2- How many forms you will be scanning and how fast they need to be scanned to be productive. The bigger, better, faster scanners (5-10 docs per minute) are going to be thousands whereas a flatbed (<1 per minute) will be cheap.
3- Storage. Hard drives are cheap now, but if you are planning on keeping the entire scanned document archived (7 years by law in most states), you need a lot of disk space.
Dave S.

 

[FoxAl]

Thanks!

Rick, I take the point about adding new functionality to old software but VFP is not an option currently. If the customer wants it and it is available, then we are merely the messengers in providing the goods.

Dave S, I appreciate the lengthy reply and info and welcome the warning re high costs both financially & in time. However as we are not/cannot use VFP currently, can the Scanning Documents Functionality co-exist with Foxpro for DOS 2.6a?

PS: How do I assign points/grades to you both for the helpful info?

Regards
AliFox

 

[DSummZZZ]

As I said, it's been a while since I was doing that project so the intercommunication using ODBC or maybe even direct Fox table compatability may have improved since I used it. At the time though, using the software I was given, I had the option of using an ODBC driver to connect to Fox tables or placing the scanned info into a flat text file that could be imported upon completion of scanning a batch of documents.
So in short, yes. There's always more than one way to do it using Fox!

PS: To award a 'star' to a post you feel is useful, just click the link below the post you think is useful that says:
'Mark this post as a helpful/expert post!'
Dave S.

 

[DSummZZZ]

Let me also point out an omission from my earlier posts. I was using FoxPro 2.6 DOS.
Dave S.

 

[MorgyDogy]

I have done some work with scanning.

Let me know if you still are interested.

 

[FoxAl]

MorgyDogy,

Thanks for the offer but this post was made Dec 2002 - 18 months ago!!

It has long since been closed and advice offered to user was that it was not feasible.

I'll keep your alias in mind though should anyone else ask.

FoxAl