Jim Lawrence
accessd at shaw.ca
Thu Sep 9 20:44:48 CDT 2010
Hi Stuart: Back in the days of simple HTML and stable sites it was easy to scrape and push data into a site. It is still relatively easy to scrape but sites are much more dynamic. OTOH, if the site developers have been doing their job, emulating data input using a copied page is almost impossible. The only way might be through the key board buffer. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan Sent: Thursday, September 09, 2010 2:48 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Scroll button If the page never changes and you always fill in the same fields, AutoIt would do it easily. Dump your Access data to a text file and write a small AutoIt application to read the data, open the wepage in a browser, step through form fields on the page and insert the data into the appropriate ones. Probably only a few minutes work. -- Stuart On 9 Sep 2010 at 12:27, Jim Lawrence wrote: > 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_service > s_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-expl > orer/ > > 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 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com