Hi -- we are a small manufacturing looking for a multi-user database to
take customer orders (nothing too complicated, with 3 users total).  We
think we should be using Access, but are wondering what alternatives
there are.  It has been recommended to us to use ASP.net and SQL
instead, with the reasoning that:

1) Access is likely to go obsolete at some point
2) It will be more stable

Does anybody have any thoughts on this?

Allison,

Your situation sounds like an ideal task for Access. As for Access
being obsolete anytime soon I don't see that happening. Access can
handle 3 users no problem.

I would recommend that you get the Access database setup by someone
with some database experience as a poorly designed database regardless
of the application could have problems.

The ASP.net and SQL server options would require much more development
time and money.

Just my two cents...

Good luck,

-Joe

"Allison" <marimbasherry@gmail.com> wrote in
news:1140204889.603121.190570@f14g2000cwb.googlegroups.com: 

> It has been recommended to us to use ASP.net and SQL
> instead, with the reasoning that:
> 
> 1) Access is likely to go obsolete at some point

The person making the recommendations is clearly quite ignorant of
reality. Microsoft has already invested a huge amount of work in the
next version of Access, Access 12, which will be released as part of
the next MS Office suite, which I expect to be released along with
Windows Vista next year. 

From the documentation that has been released about the beta version
of Access 12, it looks like a significant upgrade, though so far,
most of the changes seem to me to be in end-user features, rather
than in features for developers of applications, but the record on
all of this is incomplete (there's a blog devoted to Access 12 at: 

  http://blogs.msdn.com/access/default.aspx

and the discussion there has mostly been devoted to an overview and
the beginning of a detailed discussion of the new features, which so
far have just gotten through some parts of the revised UI). 

It seems pretty clear to me that Access is going to be around for
the long haul, though it may be rather different in new versions.
But Windows Vista is itself going to be rather different from
earlier versions of Windows, so it would be odd not to expect Access
to evelve along with the new user interface features. 

> 2) It will be more stable

Define "stable."

An ASP/SQL Server application will be much, much more expensive to
implement, less feature rich, and probably have slower performance
(because it takes more screens in a browser-based application to
replicate all the functionality that can be included in an Access
form). With 3 users and a properly functioning network, there should
be no difference whatsoever in stability. 

But the real answer would be to compare the cost of an Access app
with the cost of an ASP/SQl Server app. I would expect a multiplier
of at least 5X for the browser-based app. 

The only real advantage for the browser-based app is portability,
but that isn't much of an issue any longer, either, as Windows
Terminal Server makes it extremely easy to make an Access app
available to remote users with the installation of minimal client
software (Remote Desktop Connection is pre-installed on all WinXP
PCs, so for them, there's no client installation at all). 

Do the numbers and if the quotes you get are actually honest, you'll
see that the Access app is clearly going to win on a cost/benefit
analysis. If the numbers are not as widespread as the 5X or more
I've suggested, then you're probalby comparing apples to oranges in
terms of functionality. One way to work that out is to give the
quotes to the competing developers, i.e., the ASP quote to the
Access developer and the Access quote to the ASP developer, and then
let them point out what's missing from the competing bid. This
process will probably be an eye-opener. 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

"To take customers orders?"   Don't bother... buy a off-the-shelves
solutions as Quickbook.

"Allison" <marimbasherry@gmail.com> wrote in message
news:1140204889.603121.190570@f14g2000cwb.googlegroups.com...
> Hi -- we are a small manufacturing looking for a multi-user database to
> take customer orders (nothing too complicated, with 3 users total).  We
> think we should be using Access, but are wondering what alternatives
> there are.  It has been recommended to us to use ASP.net and SQL
> instead, with the reasoning that:
>
> 1) Access is likely to go obsolete at some point
> 2) It will be more stable
>
> Does anybody have any thoughts on this?
>

"Allison" wrote

 > Hi -- we are a small manufacturing looking for
 > a multi-user database to take customer orders
 > (nothing too complicated, with 3 users total).
 > We think we should be using Access, but are
 > wondering what alternatives there are.  It has
 > been recommended to us to use ASP.net and
 > SQL instead, with the reasoning that:
 >
 > 1) Access is likely to go obsolete at some point

All software will "go obsolete at some point". On the other hand, some 
mainframe code that I wrote in the 1970s is still in use. Access is the 
database component of Microsoft Office and (Microsoft isn't saying) the 
concensus is that Microsoft Office has well over 90% market share. That 
tells me that even if every other database in that marketplace _doubled_ its 
market share, Microsoft would still have the vast majority. It is also a 
concensus that Office is Microsoft's "cash cow". Companies in business to 
make money, and Microsoft _is_, do not kill off their "cash cow" nor do they 
allow it to "go obsolete" due to neglect.

 > 2) It will be more stable

ASP.NET with SQL Server "more stable"? First, you can't reproduce with 
ASP.NET the kind of rich-client front end that you can create with Access --  
ASP.NET applications are used through a web browser and web browsers just 
don't have that kind of user interface capability. And, even if you could, 
it would take (pardon the technical terms) "oodles, gobs, and bushels" of 
hand-coded HTML, VB.NET or C#, to do what a simple Access database would do. 
(Get that, new, hand-coded, still have to be tested... Most of what you do 
with Access is done for you _by_ Access, and much of that has ten years of 
testing by millions of users behind it.) Too, it's my experience that 
typical ASP, ASP.NET, classic VB, VB.NET, classic C, C++, C# developers 
don't know very much about what a database really is, how to use a database, 
etc., and you often end up with code that, politely put, "does not make the 
best use of a database".

Could I venture a guess? I'd guess that the people giving you this 
misleading advice are people who create ASP.NET applications for a living, 
and, perhaps even, _sell_ licenses to SQL Server. If not, I'd guess it is 
people who have already been misled by someone in those categories and are 
passing on the bad advice they've received.

If your three users are on the same LAN, it would be sheer folly to invest 
in writing a web-based application (as ASP.NET would be). It would be costly 
(several times as costly as an Access database application), and, in fact, 
probably not _nearly_ so stable.

 > Does anybody have any thoughts on this?

We hear/read this kind of thing, both first and second hand, in the 
newsgroups every day. Often it even comes from people who either do, or 
should, know better. It has been my pleasure to explain and demonstrate, in 
person, to a number of people just how misleading it is. Most of those 
people are now happily using an Access user interface to whatever database 
engine they chose.

That is, with Access you aren't limited to the included Jet engine, nor the 
free, included MSDE (a performance-limited version of Microsoft SQL Server), 
but can use any ODBC-compliant database for your data store. And, believe 
me, you stand a far better chance of successful use of MS SQL Server using 
Access and MS SQL Server's ODBC driver than some non-database programmer's 
ASP.NET application and Microsoft SQL Server by that non-database 
programmer's newest generation of hand-coded data access.

On the other hand, Saintor makes a good point -- there are relatively 
inexpensive "canned solutions" available. If you can find one that adapts 
easily to your business model, or if you can adapt your business model to 
the canned solution, that is likely to be a cost-effective solution in the 
long run. On the other hand, people have been creating or hiring someone to 
create "custom business solutions" for them since the earliest days of the 
computer age, because they wanted something that supported the way they were 
already successful at conducting their businesses.

  Larry Linson
  Microsoft Access MVP

If someone capable designs and creates the application it doesn't
matter what you use. If someone who is not capable designs and creates
the application it doesn't matter either. You already know someone
really out of his/her depth; he/she made the recommendation.

Buying something shrink-wrapped might be your best bet; but I find
things that begin with "Quick" slow, clumsy and limited. My opinion is
that they were invented for the use of Accountants who charge by the
hour to do data entry with them.

Thank you for your responses.

One of the reasons we don't go with a pre-packaged solution (i.e.,
Quickbooks Manufacturing) is that the company owner has specific
requirements for the database no solution we've encountered has been
able to accommodate.  (We've had to buy and return Quickbooks
Manufacturing, as well as another similar type software.)

I guess another possiblity is to use Filemaker, but we live in a fairly
isolated community and are worried about the fact there would be
limited access to other Filemaker experts should the one we know
decides to leave, for whatever reason.

The other reason the programmer is recommending .ASP with SQL is
probably because one of our "wish list" (not essential) features is for
salespeople to access the database when they are out of the country.
(For light occasional usage, not heavy usage.) We would think there are
other third party solutions that can do this in conjunction with
Access, but maybe I am wrong.  Anyone have comments on this?

When you introduce the internet usage then ASP with SQL makes much more
sense.