convincing a client to go with dotNet instead of Access project

  • Thread starter Thread starter bill
  • Start date Start date
B

bill

I am trying to convince a client that dotNet is preferable to an Access
project (ADP/ADE).

This client currently has a large, pure Access MDB solution with 30+ users,
which needs to be upgraded.

I believe a dotNet solution is better, but I'm trying to be as convincing as
possible -- and maybe I'm wrong!

I would appreciate any input or references which could help me.

My reasons for going with a dotNet solution are:
- The multi-tier environment is more desirable because it is easier to
deploy updates, such as a centralized web service, or as web forms
- The ADP is less efficient because it requires a continuous connection
to the backend database, whereas ADO.NET is disconnected
- I can use object oriented techniques, such as inheritance
- A dotNet solution requires less bandwidth (some users will be accessing
the database over a VPN pipe)
- Code can be re-used more easily

The ADP promoter cites the following arguments:

- Access has better reporting capabilities
- Access is quicker to develop in
- The ADP is just as efficient as a dotNet solution in terms of data
access
- The front end is already built in Access

Thanks!
Bill
 
I've had this "fight" before and lost. :< Fortunately for the client the
apps life was only supposed to be six to twelve months long. Unfortunately
for the client, we ended up creating a release a week in the last phases of
development. :<<<< Deployment out to regional office was a NIGHTMARE! We
didn't have probs with synchronization cause we used Access for the forms
creation/execution only. We were using Access to access a central SQL
Server. However, like you mentioned, I believe using something VB in my
case (or C# in your case today :>) is the better way to go. BUT, possibly
your biggest hurdle will be the front end is already developed in Access. :<
That is hard to compete against.

Cons to using C#
-new paradigm, language, IDE, manager are always afraid of change
-learning curve for language, APIs, deployment management, etc
-hey Access is better than using java/swing to do it!
-hey if the UI is in Acces why change? that's a tough one you probably
can't argue against, MS afterall isn't going to rewrite MS Office in C# from
C++ over night

Pros to using C#
-huge integration with SQL Server
-MUCH better form design support in VS than in Access (IMHO that is)
-better multi-user architecture in WinForms than in Access
-better control over version control, source control, setup programs
-opportunity to easily document code (UML, documentation from code comments)
-opportunity to extend the "reach" of the application with giving it a web
front end later on, maybe webservices, RSS, etc
-Access really tops out with performance after six concurrent connections
(does your manager know that?)
-better support for code/development help with C# than with Access (ok,
that's a bit of exaggeration, but I'm biased :>)
-with .NET you can use Crystal Reports, which is MUCH superiour to Access
for reports (if that is truely a main concern for management)

Having said all this, you might be fighting a losing battle. Good luck to
you, but you might have better luck with a future project than with this
one. But that's cool, you're setting the framework with management about
the pros/cons of .NET. Also be careful when you compare .NET to Access.
Access is the DB, and also the development and runtime environment. .NET is
the framework, VB.NET and C# are the languages you code in, and VS2k3 is the
development environment (which I'm sure you already know that :>). I see
unfair comparisons with java to .NET, that's like apples and oranges, .NET
to J2EE is the fair comparison, like C# is to java, or WinForms to Swing.

Good luck with this! :>
 
I've had this fight, too, and initially lost but won in the long run. The
Access project works for shorter term projects that can tolerate a certain
amount of sloppiness. Granted, it is hard to give an example of something
that cannot be done in Access but the .NET infrastructure lends itself to a
much more polished, secure, controlled and scalable solution. The .NET
solution lends itself to a well organized, object oriented, solution while
Acess projects often grow into a spegetti type mess.

The problem is that your counterpart is right about how quickly things can
be developed in Access. In the short run you'll get further, faster, with
Access. However, once you get the .NET environment setup it is very quick
and easy to reuse existing logic to create additional pages. You won't end
up having to re-write the .NET project but you are likely to outgrow the
Access solution.

Your counterpart's argument about Access's nice reporting interface is
correct but you should look into SQL Server's reporting services. It really
offers a nice range of options for output and some nice drill-down options
that you won't find in Access. It is always possible to step into this
transition by keeping a "Reports" project that ties into the same database.

Finally, I'd focus on security because that is something I see as a big
difference, depending on how good you are about protecting data in the Access
projects. Often, users are given select permission on entire tables. This
means that they could create a new project and play all sorts of havoc with
your data. The .NET solution is likely to make better use of stored
procedures and a much more sophisticated security infrastructure.
 
Do you have reference for the performance threshold of 6 concurrent
connections that I can point to?
That would be good documentation to have...
Thanks!
 
Do you have reference for the performance threshold of 6 concurrent
connections that I can point to?
Click to expand...
I tried doing a quick search, but wasn't able to find anything. :<

The last time I had this problem, I quickly whipped up an Access db, and
accessed it using Access forms, and a VB form, and started loading up the
number of concurrent users. And although Access was willing to accept the
other connections (7+), the performance started to decrease, almost
exponentially. Maybe it was the size of the db, or the type of data I had
in there, but it was quickly evident it wasn't going to be work for our
situation.

To help show your boss just how good .NET stuff is, maybe this is a
worthwhile scenario to test out? Create an Access DB, an Access form, a C#
app as well as the same DB in SQL Server. Then have the forms (Access and
C#) bang against each and see out of the four where the performance
bottlenecks are. Try to use threads in the C# apps to truely get the
concurrency thing going, just a suggestion.
That would be good documentation to have...
Click to expand...
I know! :< But I'm sorry, I wasn't able to find any. I think that was more
tribal knowledge at that time. Sorry about that, I'm doing java/jdbc dev
during the day now, just getting back into MS dev (C#). The best I could
find was articles talking about a limit of 255 concurrent users. However,
they also talked about the bigger the db, the worse your performance as the
number of concurrent users increased. So that 255 max is still a
theoretical number still.

I would suggest whipping something up to show your boss the .NET
flexibility, ease of development, ability to do proof of concept, as well as
taking owership and R&D initiative. Good luck!
 
Flip,

Why are you using so definitely C# and set that off against Access and VB.

I thought that the question was Access or Dotnet?

Cor
 
Bill,

I think that it will be hard to go. However, your winning point can be in my
opinion the VPN connections. With Access on low band wide you probably have
to use Citrix or any other terminal server. (However when it is Belgie than
you have probably at least ADSL and can that be less important)

With dotNet you can think on more webservice applications. Where you do the
database handling over the VPN line using the webservice, while the client
has at his location a rich client application.

Some weeks ago a message like yours was crossposted to the Access newsgroup.
They told that everything can be done with Access. This is probably not
true, however most in house office business problems can probably be solved
with Access, where it is made for, and has a large group of users.

I find it forever hard to give opinions about this. Access has progress and
dotNet has progress. Now my interest is with dotNet. That I cannot compare
with experiences with Access in the past. Therefore, try it as well in an
access newsgroup. It can be very interesting when you crosspost that with
this newsgroup, than we can follow that as well and maybe give comments.

However just an idea

Cor
 
Having developed in Access, VC++ 6, VB 6 and now starting to develop in VB
8, I have discovered that Access's forms provide far more events to program
to. Some of these events are nearly impossible to duplicate in VB 6. In
fact they don't even have counterparts in the Windows API itself. Depending
on the actual form events being used, you may discover that the Access
application is extremely difficult to port to any other language.

Mike Ober.
 
I read somewhere on the MS web-site that the threshold is somewhere between
5 and 10. If most of your data connections are reading only (they can be
read/write connections, but used only for read), you can get decent scaling.
However, if your application is heavy on database writes, performance will
suffer as you go above 5 to 10 concurrent writers. Also, there is a hard
limit of 255 concurrent connections to an Access database.

Mike Ober.
 
Why are you using so definitely C# and set that off against Access and VB.
I'm not set against VB.NET. I have my VB MCSD after all. It's just they
are both .NET languages and since you can do the same stuff in both (pretty
much for the most part), C# is quicker to type. As for using Access as the
backend, I think with the right, uh, wrong number of users (>2/3 doing
inserts and deletes), it's not the right solution, IMHO.
I thought that the question was Access or Dotnet?
Click to expand...
It was, you are right. However, the question is comparing a RDBMS to a
framework. The RDBMS is lightweight, and provides the DB, UI, development
and runtime environments. The framework, well, provides everything, but at
the sametime nothing. You have to code to the framework to get everything
but cannot DO anything if you have nothing. All that to attempt to say, the
question, IMHO is the classic apples to oranges comparison. Not a big
thing, I fell into that trap a while ago too, and I'm still learning (please
don't get the idea I'm some guru, I'm far from it). But if the question was
..NET to J2EE (no flames please :>), that might be a more direct comparision.

Having said ALL that, I believe the heart of the question is to .NET or not
to .NET? And in my opinion that is a very fair question, wouldn't you
agree? That is something I'm sure will get the people in the Access
newsgroups hopping! :> Should someone just use Access for the back end DB
and use C#, or VB.NET? Or save their $, keep their investment in the Access
db and the front end, bite the bullet and suffer what ever consequences
there are in the name of saving some money?

As a developer, GO .NET! :> But that might also be why I'm not a sr
enterprise architect yet. :<<<< Bill, keep that last point in mind. :< As
a manager, keep the $ in the bank for when sales start to slip, and suffer
the short term hiccups (after all it's not them that are suffering those
hiccups, it's the lowly users and developers).
 
Flip,

I had nothing with the content of your answers, however you was so
consequently going in the direction from C#, that I thought I never will
know why when I don't ask it.

A week ago there was a big discussion mainly from Access adepts, who told
that Access is forever the better choose about dotNet. I will never give
that answer. We cannot see from a newsgroup what is the overal situation,
education, hardware, the expected investment money, etc. from the client.

:-)

Cor
 
A number of questions to consider: What background does your client have?
If you get much deeper than "only a few can be making changes at once", are
the other arguments going to mean anything to him? Will many of the other
arguments just be "buzzword-compliant"? Will he be swayed by "214 million
computers have Access installed' or whatever the number is?

Why is the current solution being upgraded? If it's performance-related,
that's a big chunk of your argument. Newer versions of Access may not give
much better performance.

Are they looking to "fire and forget", essentially a new face on an old
program, or heavily revamp with potential for a fair amount of future
changes/releases?

A less technical argument might be to point to how MS positions the two
products. There's a reason why Access isn't under the developer section of
MS' website. It's aligned with the Office products as it's not positioned
as being a full-on development environment. This is oversimplifying, but in
essence, Access is a power end-user tool that some grown over the years to
be able to do some pretty good stuff. .NET is a developer's framework that
is intended to build serious applications.

You're not going to find much in the way of definitive comments that cast
 
Back
Top