Another good question, one that sadly would require a whole book to answer
at.
The first chapter would probably deal with a list of the many limitations
and bugs of ADP. For example, ADP is practically unable to understand more
than a single schema name (with exception here and there) and it shows
additional bugs when this schema name is anything but dbo. A little problem
at the beginning when SQL-Server 2000 started but now a much bigger problem
with SQL-Server 2005 (and soon 2008) and one that will become worse and
worse as people start using the advanced features of schema naming provided
by SQL-Server 2005-8. Of course, if you don't use these and the only schema
present in your database is dbo. then you don't have this problem but in all
case, should be very long before you arrive at a new client site and notice
an extensive use of advanced schema naming.
Another problem is the lack of control over the transactions for bound
forms. Notice that at the beginning, after the launch of ADP-2000, they
have been promised by MS that they will be included in the 2002 version,
then in the 2003 version, then nothing.
The lack of control over the parameters for the resync command (nothing else
but the primary key), the absence of any Insert, Update and Delete commands,
the inability to access anything else but a direct link to a single database
at a time all severily limit the capabilities of ADP. (Not only .NET can
access/update multiple databases at a single time for a single form but it
can also use anything else, for example it can use a web service to access a
database protected by a firewall on a local LAN or even over the WAN;
something totally unavailable with ADP unless you start coding your own
messy code using unbound forms.).
Finally, I won't pass any comments on the support for Images and other Blob
files offered by Access and on these little things like the near total
absence of control over localisation/internationalisation/collation
problems. Of course, other things like the Notification Services, Microsoft
Message Queuing (MSMQ) Services or using a local storage are totally out of
question or might be very complicated to access for ADP or MDB/ACCDB.
(Notice that I don't want to enter into the details of each particular case
here in order to simplify the discussion.)
It's a fact that .NET is slow and need a powerful motor to make it advance
at a reasonable peace but at least, it offering you access and control about
anything you might think of. Excerpt for the speed problem (something that
will soon be solved by more powerfull hardware), you'll find it hard to
simply find something that it's not there. With ADP or MDB/ACCDB, doesn't
take long before having your head hitting the walls/ceiling and unlike the
speed problem of .NET, this is something that will never get solved. With
the soon the be released version of SQL-Server 2008 and VS 2008, the
situation will become even more unconfortable for ADP and MDB/ACCDB.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
Robert Morley said:
So ignoring web apps for the moment, which are not currently a significant
concern for me, what other reasons are there to switch from Access (of
whatever form) to .NET? The last time I looked at it, I found no
compelling reasons to move in that direction at all, and in fact, found
several major blocks to moving in that direction.
Rob