Jim Lawrence
accessd at shaw.ca
Thu Sep 9 14:27:06 CDT 2010
Hi John: It is all possible but it requires building automation to do this. I have had some experience with screen scrapping but what you want is the opposite...auto-screen data web entry. Because you have no access to the internals of the web site and the site is most likely setup to stop any data entry through a custom front end you would have to create a looping key logging type app. If you could capture all the keystrokes from the moment of website entry, through the form, populate the data, save record and loop until done. Many years ago I had a little command line app that would read from a text file and write to the keyboard buffer. I used the kludge technique to upload a series of invoices to a closed accounting application...it worked very well. If you are interested I can do some digging as the app is over 20 years old but I am sure I stored it somewhere. Rather than re-write a screen key pad macro there are now a number of products out there that are already built... how good they are I have no idea but here is one: http://www.iopus.com/ HTH Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, September 09, 2010 11:32 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Scroll button Ken, I guess I wasn't clear. The web site is from the state of Pennsylvania. I didn't write it, nor do I get any input. So I get no input on the right way. The bottom line is all I need is to send them a CSV or similar file. But they don't even accept that. Nope, every person in the state who wants to enter data into their system gets to spend hours every week poking data into a web form. THOUSANDS of man hours monthly across the state, I am sure. This is the front end to being paid by the state of PA for all therapists and agencies that wish to bill the state for services to children (and maybe just services generally). Do you get a clue why medical costs are so high in this retarded place? Now for the wrong way. Yep, it sucks but it has to be better than click / click / paste / repeat for hours on end. And my app is at least SOMEWHAT automated. I am sure most are manually TYPING the data into the state form. Asking thousands of people to enter their specific 10 pieces of information into 200 controls on a "one size fits all" web page, doing this over and over for hundreds of billing records every week is asinine! Do I sound irritated? That would be because I AM irritated. Stupidity irritates me. 8( Or maybe this is PA's equivalent of a "full employment" plan, to keep people off welfare? ;) All of this data is in my database. I could just press a button, dump it to CSV file and email it or FTP it to the state, but no, my client hires people for hours every week to manually enter this into PA's web page. Sigh! John W. Colby www.ColbyConsulting.com On 9/9/2010 1:54 PM, Kenneth Ismert wrote: >> jwcolby: >> >> ... I would dearly LOVE to programmatically find the data in the web page >> and insert it myself but I do not know how to do that... >> > > Well, there is the RIGHT way to do it, and the WRONG way... ;) > > First, the RIGHT way: > > Build a web service that allows you to update the records in a completely > generic, standards-compliant way. Any properly-credentialed client could add > or update information on the site. This would add the most value to what you > are giving your client. > > SOAP > On the web side, you first would build a WSDL file which describes the > service, then you would have to build a web service that supports entering > the data, and returning success or an error. On the Access side, there are > SOAP and REST COM automation objects that let you interact with a web > service via VBA. I have used the SOAP object with VBA to interact with a PHP > SOAP web service that I built, and it works. > > Here is an overview, using the SOAP Toolkit 2.0... > http://www.soapuser.com/client4.html > > The latest is SOAP Toolkit 3.0 -- here is an example on the VBA side: > http://oreilly.com/pub/h/1306 > > REST > REST web services are simpler than SOAP, because you don't have to build a > WSDL file describing the service. Calling is simpler, too, because you just > create GETs or POSTs with data to URIs. Actually, building the web service > is easier, too, because you don't have to decode a SOAP XML request to > figure out what to do. > > Excel, VBA, and REST URLs - A Sample Application > http://developer.webtrends.com/community/dx/blog/2009/08/26/excel-vba-and-re st-urls--a-sample-application > > How to call web services with REST instead of SOAP > http://www.oreillynet.com/windows/blog/2004/09/how_to_call_web_services_with .html > > REST is not CRUD, and here's why. > http://blog.punchbarrel.com/2008/10/31/rest-is-not-crud-and-heres-why/ > > > Then there is the WRONG way: > > Automate Internet Explorer to fill in the forms programmatically. This is > wrong because it binds you to a particular browser, and will break if they > change their web page. > > You would start an IE instance in code, and traverse the DOM tree for the > page until you found the HTML that held the web controls you were looking > for, and fill them in, and programmatically 'click' and update control. > > Depending on the complexity of the HTML page, and how it is structured, this > could be moderately easy or very hard. If they want to interact with the > browser while your program is working, that may add additional complexity. > > Automate Internet Explorer > http://www.codeforexcelandoutlook.com/excel-vba/automate-internet-explorer/ > > InternetExplorer Object > http://msdn.microsoft.com/en-us/library/aa752084%28VS.85%29.aspx > > -Ken -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com