[AccessD] Scroll button

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




More information about the AccessD mailing list