[AccessD] Serving reports to the web

This is how it all starts... and where I make my wages fixing these things.

You will need a box to act as an IIS server on the network. Pretty much as
Drew said. It does not need to be a server class machine, most modern
desktops have enough horsepower for what you are likely to be doing. Simple
RAID should be safe enough. 3500 potential users isn't that much, especially
if it's unlikely for then to be requesting claims all at once. In any case,
if it does turn out to cause a problem, then you can easily upgrade the
hardware with proven justification.

You'll need to make sure you can get your IIS box exposed to the outside
world through the T1. It should get a fixed IP address, and a name mapped to
it. Check with the ISP, they should know what you need to set up for this.
The key thing is where the DNS servers are being hosted. Since you have a
T1, this shouldn't be any problem to set up at all. You can even bring the
current simple web page hosting in house, so that domain is hosted.
Otherwise you'll actually need to get another domain name for this service.

Once you have the IIS setup, build a simple app to display the claims data
after the user enters in identifying information and the claim number. Pull
the data directly from the Access BE, or a copy or synchronized other BE.

Does this answer what you were wondering about?


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
Sent: Wednesday, December 21, 2005 11:13 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Serving reports to the web

And therein lies the problem.  No of external users unknown.  One of the
owners of the company is "selling" their services to a potential new client,
i.e. a new package where they take over administration of claims from a
company that the potential client is not satisfied with.  Details unknown
(to me).  The thing I know though is that once the floodgates open...

So figure that the client CURRENTLY has about 3500 open claims, so figure
POTENTIALLY 3500 users asking for claim status.  How many of those users are
computer literate?

So, now you need to create users whenever a person hits the web site that
doesn't already have an account.  Obviously we have personal information on
everyone.  They have to provide SSN to us, name, address, DOB etc. in order
to process the claim.  So I am certain that we have enough info to validate
them and set up the user on the web site.

"Internal users" consist of about 40 users running a VERY complex access FE,
not something that can be turned onto a web page.  A main form with up to 20
tabs with Just-in-time subforms, various tabs displayed / hidden depending
on the policy type, business rules coded into classes etc.  Not gonna
translate to web pages easily, too expensive to port, no reason to port.

All info exposed internally, i.e. users update EVERYTHING in this database.
Sometimes only supervisors etc but someone is allowed to see/modify every
single table.

Externally, unknown at this point but I am guessing that it will be mostly
"summary" data.  Claimants would get status of their claim, perhaps payment
info etc.  Read only.  Managers would get summary info most likely.  I
really haven't been provided any details yet.

As for infrastructure, the client has resisted even a SQL Server, though
Express might just get them moving on that one.  They farm out their very
simple web page hosting.  They have a single T1 coming in with 3 64k
channels used for internet access, the rest used for phones.  NO very high
speed access even available to them for a reasonable price.  This is a small
business park, miles from the center of any town.

The company is small (60 employees) with no in-house expertise in IIS or SQL
Server, and I am not up to speed on those either.

I suggested, from simple to complex, emailing reports to a provided email
address, PDF files uploaded to a server with access to those reports through
a web page, and setting up IIS to run a web site out of their office.  With
their bandwidth issues I am not sure that the latter is doable but the owner
doing the "selling" pretty much nixed the first two and asked us to examine
the third, so there we are.

I would love to see us do this stuff, and I would prefer an in-house
solution (server) so I don't also have to handle the headache of getting the
data out to an external hosted server. 

It sounds like the hardware / software you discuss would not come cheap
though. 

John W. Colby
www.ColbyConsulting.com