jwcolby
jwcolby at colbyconsulting.com
Mon Aug 31 07:32:42 CDT 2009
The system already exists and works. What happens is that there are two scanners which are used to turn documents into tables using Omnipage. Those CSV files are dropped into a well defined directory structure on a disk drive "somewhere". ATM everything is done locally, inside of a network in a SOHO. So right now... a user scans a document into Omnipage. Inside of Omnipage she uses her mouse to surround (swipe) areas of the document that is data that is going into a table. Omnipage then turns the swiped areas into a CSV file, which the user then stores to a specific location. These are invoices which go into a state/program/subprogram kind of structure. As soon as the document is on the hard disk as a csv, the application opens the CSV and loads it into a temp table which has a field1, field2, ... field12 format. Each field maps to a named field in another table but at this level the field mapping is not done. A processes occurs which attempts to fix OCR errors. The scanner may decide that an l is a one or vice versa, a zero is an oh. Stuff like that. So the user runs the process to fix OCR errors. Once the OCR errors are fixed the application maps the field1 ... fields in the temp table into the correct fields in a destination table, and the user then looks at the data. The end objective is to perform an analysis on an invoice looking for errors. Big money involved, thousands or millions of dollars, and the invoices come from organizations who don't necessarily use high tech tools to generate the invoices, so lots of errors are found. Once the analysis is done the application stores the data table back out to a specific location, in a fixed width US Government standard format. Eventually the data is shipped back to the client. This thing is dead simple for you and I as experienced developers. A directory structure, an import, an OCR correction process, a set of mapping queries to move raw data to the invoice table. Once the user finishes the analysis, an export back out to a destination folder. What is happening now is that the client wants to bring his daughters in as employees, but have them work from home. He already has an employee in another state doing some "dispute resolution" work for him. So he wants a central server in his home office where all the documents go. His daughters will work on the application but need may need to access document CSV files that were scanned and are physically located in another state. And of course dump the processed file back to a server in another state. My solution to that need was to use Hamachi to set up a VPN network that everybody joins. The server is on it, each remote user is on it. The VPN network exposes a mapped directory, which is mapped to X:. That X: now contains that directory structure where all files are stored. So to the user, it appears that they have a local drive X: but that drive is actually a directory on a server several states away. The application simply pulls the CSV files from the X: drive and writes the result files back to the X: drive. The application already pulls documents from a mapped drive, now the drive just happens to map to a server in another state. No change to the APP. In order to test, I have already done this mapping the client's server as my X: drive, and also setting up a mapped folder on my server, remoting in and running the application where my shared drive is mapped to the X: drive on his system. It definitely works. The speed was not great (30 seconds for the biggest file) when working on files on the client's server, a PIII 500mhz 256m RAM Windows XP. OTOH it was about 9 seconds when running the application on that remote server and pulling the data off of my server. It was about 5 seconds running completely local on his end, so the trip over the internet "cost" about 4 seconds when talking to a modern server. So we are discussing replacing a working application, a software VPN - Hamachi - and a mapped drive, with a web service that reads and writes files to a server. The service would need to run on the server I assume, which means getting that server running IIS. BTW the client purchased a new DELL box with XP installed to act as the server. I would have to get IIS running, write the services to read and write files, and write something for the existing application to connect to the services to perform the reads and writes. I assume that I would have to read the files to a local drive and then run the import as I do now (this is currently Access). Write the files locally and then send them via the service back to the server. Again, I am rewriting this application to C#. In C# this whole thing might very well make sense, since I could just read the stream from the web service and place the results directly into a table. Using the current Access App I would have to do some modifications to a working app to interface to the service. John W. Colby www.ColbyConsulting.com Eric Barro wrote: > Didn't the original spec indicate that the CSV file would be dropped into a > web location where the client machines could pick them up? > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan > Sent: Sunday, August 30, 2009 4:30 PM > To: Discussion concerning Visual Basic and related programming issues. > Subject: Re: [dba-VB] SPAM-LOW: Re: Access data across the internet > > The only reason it "goes away" is because web services use the standard HTTP > port 80 > which is open by default on most routers. That means there is no > configuration needed on > the client machines. > > But you will still need "IT" to configure the router and set up port > forwarding to point to the server hosting the web service. Of course, this > is not an issue where you set up a web service on a public web server, but > that is not what you are trying to do - you want something hosted internally > which can access your internal file systems and databases and interface in a > controlled manner with other machines. > > There's nothing to stop you from using the same port 80 for your own TCP/IP > Listener application. > > You can also any of the other "standard" ports which are likely to be open > on a router such as FTP (21), SMTP(25), POP3(110) etc > > I have a couple of such Listener applications which do the sort of things > you are after, but they are written in PB/Win - if you want to look at them > to get a better idea of oterh way you can do this, I will send the source to > you off line. > > > -- > Stuart > > > > On 30 Aug 2009 at 18:18, jwcolby wrote: > >> Thanks Stuart. >> >> I believe one of the implications of the service route was that the whole > TCP/IP address / port >> thing goes away, IOW it can get through a firewall without having to get > the intervention of IT. >> I am listening to all points of view. Luckily I am in no hurry here, it > will be six months or more >> before I need to solve this problem, or even have the requisite knowledge. >> >> John W. Colby >> www.ColbyConsulting.com >> >> >> Stuart McLachlan wrote: >>> WCF, SOAP, Web Services etc are necessary if you are exposing services > to all and >>> sundry on the web. >>> >>> There are far simpler ways to exchange data when you have control of > both the client and >>> the server. These other methods do not require you to set up a web > server and publish a >>> schema which then opens up your data to the whole world. Take a look at > a simple TCPIP >>> client/server solution first. Here's a simple one in VB .Net >>> >>> http://www.eggheadcafe.com/articles/20020323.asp >>> >>> This could be easily modified to do the sort of thing you are after, > with the Listener >>> application doing most of the work. >>> >> _______________________________________________ >> dba-VB mailing list >> dba-VB at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/dba-vb >> http://www.databaseadvisors.com >> > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > >