Prev: Spam control in sbs 2003/exchange 2003
Next: Help Needed with SMTP Settings on Exchange and ISA 2004 SMTP Add-in
From: Steve Moss on 30 Mar 2010 04:31 Thanks all for the responses. Yes, I am aware of the rights and wrongs of all this, and I am able to make (and am making) those arguments. Having technical arguments to back that up, though, would be a help. I appreciate Duncan's comments re adverse network performance - and I heartily agree - but right now that's not something that will, understandably, sway much with this client. Until recently their LOB 'application' was a very large shared Excel workbook, where client performance was appalling (10 minutes just to open or save the workbook, for instance). I suggested a SQL database replacement with local http-based access was the way to go, and set up an SQL instance for this very purpose. I also set everything up properly in IIS and allocated a folder on the server for the dev to place her files. As what was supposed to be an interim solution, an automated build of the Access database (from the Excel workbook) and ..asp files was performed, and this was a great success. Client performance is *much* better than it was. The users were delighted. Now, of course, they are reluctant to change things again and make the move to SQL. I am pushing, though.
From: Duncan McC on 30 Mar 2010 06:17 In article <xn0gs91ie2jqs2000(a)news.microsoft.com>, "Steve Moss" <> says... > > Thanks all for the responses. Yes, I am aware of the rights and wrongs > of all this, and I am able to make (and am making) those arguments. > Having technical arguments to back that up, though, would be a help. I > appreciate Duncan's comments re adverse network performance - and I > heartily agree - but right now that's not something that will, > understandably, sway much with this client. > > Until recently their LOB 'application' was a very large shared Excel > workbook, where client performance was appalling (10 minutes just to > open or save the workbook, for instance). I suggested a SQL database > replacement with local http-based access was the way to go, and set up > an SQL instance for this very purpose. I also set everything up > properly in IIS and allocated a folder on the server for the dev to > place her files. As what was supposed to be an interim solution, an > automated build of the Access database (from the Excel workbook) and > .asp files was performed, and this was a great success. Client > performance is *much* better than it was. The users were delighted. > Now, of course, they are reluctant to change things again and make the > move to SQL. I am pushing, though. Good luck and keep pushing! :) Geez I haven't used Access for 7yrs +. It just *doesn't* work on a shared network scenario once the db gets to even .5Gb - and five users or more concurrent connections. Sucks the network dry. But *you* know that. So... to keep pushing, push her to try say: * Microsoft Web Platform Installer (it's all you need to develop on the desktop). * with it - load up/install: Visual Studio Express (pick yer flavours: C#, VB, Web Developer (if yer looking at a web app, this is the one), together w' IIS, SQL Server Express (all done with the Web Platform Installer). I think, she'd be *very pleasantly surprised* and *really like* that development environment over Access. PS: Visual Studio Express 2010 beta is out too. There is also *far* more support and help for her with this sort of devel environment than there is for MS Access - including a heap of ready to go solutions that are easily modified. Hell she can even use MS Access to access the SQL Server db - but I think she'll quickly find SQL Server's Management Studio is pretty damn good on its own. It also ensures everything stays ANSI/SQL compliant for the future. -- Duncan.
From: Paul Shapiro on 30 Mar 2010 17:07
"Duncan McC" <hard(a)work.ok> wrote in message news:MPG.261c96f215eba49d989b48(a)news.microsoft.com... > In article <xn0gs91ie2jqs2000(a)news.microsoft.com>, "Steve Moss" <> > says... >> >> Thanks all for the responses. Yes, I am aware of the rights and wrongs >> of all this, and I am able to make (and am making) those arguments. >> Having technical arguments to back that up, though, would be a help. I >> appreciate Duncan's comments re adverse network performance - and I >> heartily agree - but right now that's not something that will, >> understandably, sway much with this client. >> >> Until recently their LOB 'application' was a very large shared Excel >> workbook, where client performance was appalling (10 minutes just to >> open or save the workbook, for instance). I suggested a SQL database >> replacement with local http-based access was the way to go, and set up >> an SQL instance for this very purpose. I also set everything up >> properly in IIS and allocated a folder on the server for the dev to >> place her files. As what was supposed to be an interim solution, an >> automated build of the Access database (from the Excel workbook) and >> .asp files was performed, and this was a great success. Client >> performance is *much* better than it was. The users were delighted. >> Now, of course, they are reluctant to change things again and make the >> move to SQL. I am pushing, though. > > Good luck and keep pushing! :) > > Geez I haven't used Access for 7yrs +. It just *doesn't* work on a > shared network scenario once the db gets to even .5Gb - and five users > or more concurrent connections. Sucks the network dry. > > But *you* know that. So... to keep pushing, push her to try say: > * Microsoft Web Platform Installer (it's all you need to develop on the > desktop). > * with it - load up/install: Visual Studio Express (pick yer flavours: > C#, VB, Web Developer (if yer looking at a web app, this is the one), > together w' IIS, SQL Server Express (all done with the Web Platform > Installer). > > I think, she'd be *very pleasantly surprised* and *really like* that > development environment over Access. > > PS: Visual Studio Express 2010 beta is out too. > > There is also *far* more support and help for her with this sort of > devel environment than there is for MS Access - including a heap of > ready to go solutions that are easily modified. > > Hell she can even use MS Access to access the SQL Server db - but I > think she'll quickly find SQL Server's Management Studio pretty damn > good on its own. It also ensures everything stays ANSI/SQL compliant > for the future. > > -- > Duncan. While I agree that SQL Server is far preferable for a web db, I find that well-designed Access databases and applications run fine for 50 users on a LAN. As the number of users increases, reliability decreases since each user's workstation is directly writing to the data file. I would avoid Access for more than 20 users if there is much db writing going on. I just don't think it's so unacceptable as Duncan's experience. And no, I would not install any office application on an SBS server and I would not use an Access (Jet) db for a web application running on an SBS server. Too easy for the web app to lock up the system. |