[AccessD] Serving reports to the web

DWUTKA at marlow.com DWUTKA at marlow.com
Thu Dec 22 10:53:59 CST 2005


I'd have to disagree.  Like I said, setting up an IIS server is not that
difficult, and would be far more cost effective.  You have to remember that
3500 potential external users is a drop in the bucket when it comes to web
traffic.  We average 440 unique visitors a day to our website, and it's a
desktop machine that is several years old (PIII gigahertz).

Bandwidth would only be an issue if they were running dialup.  They have a
T1, and even though only a small portion is set aside for the web, it's
still dedicated bandwidth, and would be fine for a webserver to dish out
data filled web pages.

Drew

-----Original Message-----
From: William Hindman [mailto:wdhindman at bellsouth.net]
Sent: Thursday, December 22, 2005 8:48 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Serving reports to the web


JC

...bandwidth is cheap ...Verizon is offering 15Mbps down/5 up for $50 a 
month now ...I also have a client who just converted to a T1 based VOIP 
system w/internet for a lot less than just his phone/dsl line was costing 
him and once the cutover problems were resolved, it works great ...the 
bandwidth not actually in use by the voip is available for internet access 
...and its symetrical so running a local web server is realistic for him.
...you have to explore whats available in your area of course but the 
technology is running far ahead of the adoption rate ...your client could 
easily have all the bandwidth you need for less money than he's now paying.

...but bandwidth isn't your real problem imo ...when you move to SQL Server 
for that large a potential user base you are almost certainly talking about 
them needing a notwork/dba on-site ...SS is not Access ...it requires some 
babysetting ime.

...in your situation I'd look for a really good web host who can provide a 
dedicated SQL Server hosting service that lets you focus on doing what you 
do best ...building an internal web server is something you ought to sell 
after you proof the software capability, not before imnsho, especially if 
you have no experience in doing it ...I use parcom.net for this but there 
are many, many others.

...I understand the preference for an internally hosted solution but in all 
honesty JC, I think you would be biting off a lot more than you need to all 
at one time ...syncing the data with an externally hosted server is a lot 
easier that building a total hw/sw solution from the ground up ...especially

in the environment you describe where even bandwidth is a major problem.

...for a couple hundred dollars a year you can get unlimited dl bandwidth 
plus sql server on a dead reliable host ...once you get all the asp built 
and the user interface kinks worked out, then you can look at the bennies of

doing it internally.

...else I'd be looking to use someone with a lot of experience in building 
and hosting web servers and asp/sql apps as a consultant ...there are 
certainly some of those here.

...just my two cents worth of experience doing similar things and getting 
bitten badly ...others will almost certainly differ ...its AccessD afterall 
:)

William

----- Original Message ----- 
From: "John Colby" <jwcolby at ColbyConsulting.com>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Sent: Thursday, December 22, 2005 12:12 AM
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
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Nick
> Sent: Wednesday, December 21, 2005 9:45 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Serving reports to the web
>
> This is pretty much what I do all the time. There's a range of approaches,
> but a lot depends on the details. How many external users, how often you
> need to create accounts, how many internal users. What information gets
> provided to the claimants, what information is exposed internally.
>
> For example, with ASP or even better, ASP.NET, there are ways to build
> something that would allow the internal users to essentially navigate
> through the entire database on an ad hoc read only basis.
>
> What kind of infrastructure is available for this system? There's a
> difference in what you can do if you have to build onto stuff already 
> there.
> At first glance based on the initial 40+ internal users I think I would 
> like
> a SQL server box, and internal IIS box, and an external IIS box, would 
> this
> kind of hardware be made availale?
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
> Sent: Wednesday, December 21, 2005 2:16 PM
> To: 'Access Developers discussion and problem solving'; Tech - Database
> Advisors Inc.
> Subject: [AccessD] Serving reports to the web
>
> Does anyone have any knowledge of what is required to serve reports to 
> users
> on the web.
>
> The scenario is the Disability Insurance call center, a new client, which
> wants to get access to summary information on insurance claims being
> processed for management, but eventually to allow claimants to see the
> status of their claim live, online.
>
> I need a feel for how the security issue is handled, how users / passwords
> can be created automatically, and once created how reports can be 
> generated
> and displayed based on the user logged in.  Details are sketchy, but I am
> guessing that a secure area would be created where users log in.  The 
> first
> pass would segment the users into claimants and managers.  Once logged in,

> a
> selection of possible reports (assuming that once demonstrated, the 
> reports
> will grow uncontrollably).
>
> The BE is currently an Access BE approaching 500 mbytes, pounded on all 
> day
> by ~40 users live in-house entering claims and answering calls.  How does 
> a
> web enabled app get data out.  The "boss" has already pretty much nixed
> emailing reports and downloadable predefined PDF files.  Which to me
> indicates they are looking at "configurable" reporting out of live data,
> straight to html, with strong security to keep the wrong people out.
>
> Anyone out there with experience in doing this kind of stuff?
>
> John W. Colby
> www.ColbyConsulting.com
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
> -- 
> 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