From: Steve Moss on
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
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
"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.