DWUTKA at marlow.com
DWUTKA at marlow.com
Thu Dec 22 17:50:19 CST 2005
Okay, but then you get to deal with the synching problem. Honestly, it is not that difficult to setup an IIS server, it's all wizard driven nowadays.... Drew -----Original Message----- From: William Hindman [mailto:wdhindman at bellsouth.net] Sent: Thursday, December 22, 2005 5:43 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Serving reports to the web ...for you, maybe ...but you're a geek with the stuff ...given the cost of the hw/sw plus the setup time and maintenance for someone starting from scratch vs $200 a year for everything ...certainly not me ...and I run seven servers already and a number of web sites ...granted it doesn't take much if you're not starting from scratch ...but like I said, if I didn't already have an IIS server working, I'd farm out the site hosting and focus on getting the database working right ...then tackle the internal web server side ...but I acknowledge you could probably whip it out in a couple hours ...I couldn't and I don't think its JC's bag at the moment either. William ----- Original Message ----- From: <DWUTKA at marlow.com> To: <accessd at databaseadvisors.com> Sent: Thursday, December 22, 2005 11:53 AM Subject: Re: [AccessD] Serving reports to the web > 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 > -- > 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