dotnet windows forms vs. Access

[Larry Linson]

I just wonder if I am wasting my time learning VS 2005.

I've developed in Access for a long time, and seek out advanced work
which invariably requires complex unbound data entry forms connected
to a MS SQL back end.

Taking a hard look and experimenting with dotnet 2.0 and Visual Studio
2005 to see if dotnet Windows forms might be a good alternative for
these specific kinds of jobs, so far it doesn't seem so. My impression
thus far is it's great for quick and dirty jobs, but not complex ones.

What do you guys think? Better to stay with Access and SQL Server or
not?

Use appropriate tools for the job at hand: In general, for "normal business
database applications" in a single-user, multi-user, or client-server
environment, Access is the better tool; for "web based" or distributed
enterprise applications, the DotNet environment is appropriate.

For applications which can be done with Access, there is a significant
advantage in time and effort to create and maintain the application over
doing the same thing in DotNet.

For applications which could be done in Access but for which the users or
the developers believe that user interface "glitz and glitter" is important,
and for which finances are available to license the third-party tools that
make it possible to create that glitz and glitter, and for which
implementation costs are secondary, then DotNet is the tool you want. {None
of my clients/customers, BTW, ever considered implementation costs to be
"secondary" nor were willing to pay much (some of them not willing to pay
even a nanocent) for "glitz and glitter".}

For applications which can only be done with software tools of "grander
scope", Access just isn't suitable so the comparison is not worthwhile.
There are many who prefer other "grander scope" development
tools/environments over DotNet -- as my work is all "normal business
applications" for which Access is appropriate, I don't have a dog in that
fight.

Larry Linson
Microsoft Access MVP

 

[Thomas]

Use appropriate tools for the job at hand: In general, for "normal business
database applications" in a single-user, multi-user, or client-server
environment, Access is the better tool; for "web based" or distributed
enterprise applications, the DotNet environment is appropriate.

For applications which can be done with Access, there is a significant
advantage in time and effort to create and maintain the application over
doing the same thing in DotNet.

For applications which could be done in Access but for which the users or
the developers believe that user interface "glitz and glitter" is important,
and for which finances are available to license the third-party tools that
make it possible to create that glitz and glitter, and for which
implementation costs are secondary, then DotNet is the tool you want. {None
of my clients/customers, BTW, ever considered implementation costs to be
"secondary" nor were willing to pay much (some of them not willing to pay
even a nanocent) for "glitz and glitter".}

For applications which can only be done with software tools of "grander
scope", Access just isn't suitable so the comparison is not worthwhile.
There are many who prefer other "grander scope" development
tools/environments over DotNet -- as my work is all "normal business
applications" for which Access is appropriate, I don't have a dog in that
fight.

Larry Linson
Microsoft Access MVP

I think development was faster with Access only in the early age of
..NET. With .NET you have much greater possibilities to gradually
accumulate really reusable pieces of code or create automated code
generation tools which significantly outperform Access in almost any aspect.

 

[Robert Morley]

In which case, it may get into whether you're a "power" .NET user or not.

That said, however, you have at least some of the same capabilities in
Access, as (unlike VB6 AFAIK) you can automate a good amount of form/report
generation if you have the need to do so. Conceivably, you could design a
form entirely by VBA code (much like the existing Wizards already do),
though there aren't all that many cases where you would actually do so, as a
general rule. More often, this sort of thing is used to iterate through all
Access forms to apply certain design rules (change all fonts on all forms to
Arial, as an example).

While not quite the same as the above, one example of this sort of thing
that I've done before is to write code which will size Access controls to
the largest size required to fit the same text for both 96 DPI and 120 DPI,
as well as auto-sizing combo/listboxes to their largest element. This gets
attached to a custom button in your toolbar, and as you can imagine, becomes
VERY useful in Access forms development.

Is this the sort of thing you're talking about doing in .NET? I haven't
tried it since the early days, so I'm not sure of its more recent
capabilities.



Rob

 

[Larry Linson]

. . .
I think development was faster with Access only in the early age of
.NET. With .NET you have much greater possibilities to gradually
accumulate really reusable pieces of code or create automated code
generation tools which significantly outperform Access in almost any

aspect.

Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, made
friends in Redmond with that kind of reply.

I had a C-programmer colleague back at the "major computer manufacturer"
from which I retired who said something similar about C, and then about C++,
comparing it to PL/I, Basic, and then to Visual Basic and Access. He's
likely saying the same about C#, now, but chances are the clients who can
afford him are all doing distributed enterprise apps that are web-based.

The problem is that you _DO NEED_ to "gradually accumulate" (and
purchase/license -- lots of purchasing/licensing going on in the DotNet
world) reusable pieces of code or create automated code generation tools in
order to do with any facility even the most basic of the database functions
that are built in to Access, right out of the box. That is, if you re-create
Access in DotNet, you'll almost catch up with "the real thing."

You do realize, don't you, that the statement "significantly outperform
Access in almost any aspect" is essentially content-free, don't you?
Frankly, my view is that "Access out of the box outperforms Visual Studio in
creating normal business database applications for the single-user,
multi-user, anc client-server environments". I know a few people who do both
Access and DotNet, and they agree with me; the ones who don't are those who
don't now use, or perhaps never have used, Access and think it's just a
"junior version" of DotNet.

The essential functionality needed for controlling the application,
navigating, and manipulating the database is ALREADY THERE with Access, so
all you have to do is put in the business functions (and, unless you develop
very similar applications for multiple businesses, it's not going to be
useful, and depending on your agreement with your clients, may not be legal,
to "package" their business functionality as "really reusable pieces of
code".)

I spent some of the early part of my career creating development tools. It's
interesting work, but it's not something an application developer should
have to do in order to get decent development for their investment of time
and effort, or to be able to accomplish what they need at all. It's a lot
more productive for the application developer to develop applications, not
tools, not create and accumulate libraries.

Larry Linson
Microsoft Access MVP

 

[Thomas]

In which case, it may get into whether you're a "power" .NET user or not.

That said, however, you have at least some of the same capabilities in
Access, as (unlike VB6 AFAIK) you can automate a good amount of form/report
generation if you have the need to do so. Conceivably, you could design a
form entirely by VBA code (much like the existing Wizards already do),
though there aren't all that many cases where you would actually do so, as a
general rule. More often, this sort of thing is used to iterate through all
Access forms to apply certain design rules (change all fonts on all forms to
Arial, as an example).

While not quite the same as the above, one example of this sort of thing
that I've done before is to write code which will size Access controls to
the largest size required to fit the same text for both 96 DPI and 120 DPI,
as well as auto-sizing combo/listboxes to their largest element. This gets
attached to a custom button in your toolbar, and as you can imagine, becomes
VERY useful in Access forms development.

Is this the sort of thing you're talking about doing in .NET? I haven't
tried it since the early days, so I'm not sure of its more recent
capabilities.



Rob

Rob, I agree it's a lot about question if somebody is a "power" .NET
user or not. But this should not be an excuse for not to stick with .NET
(it's easier to ride bike than drive car, too).

Otherwise, I've just wanted to point out that time needed to produce a
business application could be on the .NET side. Of course you can do a
lot of code generation things with VBA and you also get a lot of
built-in wizards in Access, too.
As you say, form or report creating wizards are not of much use. In my
opinion, developer should think in another way - his/hers job should be
only to create code which demands hard brain work. Dropping textboxes
and labels on the form, binding them to the database fields, arranging
them on the gui controls etc. is not that type of work and it should be
done automatically. Developer should focus only on the special
customer's needs, business rules which are different for each
application, some special gui controls etc.

 

[Thomas]

aspect.

Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, made
friends in Redmond with that kind of reply.

I had a C-programmer colleague back at the "major computer manufacturer"
from which I retired who said something similar about C, and then about C++,
comparing it to PL/I, Basic, and then to Visual Basic and Access. He's
likely saying the same about C#, now, but chances are the clients who can
afford him are all doing distributed enterprise apps that are web-based.

The problem is that you _DO NEED_ to "gradually accumulate" (and
purchase/license -- lots of purchasing/licensing going on in the DotNet
world) reusable pieces of code or create automated code generation tools in
order to do with any facility even the most basic of the database functions
that are built in to Access, right out of the box. That is, if you re-create
Access in DotNet, you'll almost catch up with "the real thing."

You do realize, don't you, that the statement "significantly outperform
Access in almost any aspect" is essentially content-free, don't you?
Frankly, my view is that "Access out of the box outperforms Visual Studio in
creating normal business database applications for the single-user,
multi-user, anc client-server environments". I know a few people who do both
Access and DotNet, and they agree with me; the ones who don't are those who
don't now use, or perhaps never have used, Access and think it's just a
"junior version" of DotNet.

The essential functionality needed for controlling the application,
navigating, and manipulating the database is ALREADY THERE with Access, so
all you have to do is put in the business functions (and, unless you develop
very similar applications for multiple businesses, it's not going to be
useful, and depending on your agreement with your clients, may not be legal,
to "package" their business functionality as "really reusable pieces of
code".)

I spent some of the early part of my career creating development tools. It's
interesting work, but it's not something an application developer should
have to do in order to get decent development for their investment of time
and effort, or to be able to accomplish what they need at all. It's a lot
more productive for the application developer to develop applications, not
tools, not create and accumulate libraries.

Larry Linson
Microsoft Access MVP

Larry, don't get me wrong. It's really not about being a DotNet fan (and
I believe you can get friends in Redmond speaking friendly about Access,
too).

I do work right now (and was working for several years in the past) both
with Access and .NET, and I'm just comparing both of the worlds.

Speaking about the licensing "problem" - I think we should calculate if
this is really the drawback of the .NET. Most of the components typical
developer needs are royalty free so you have to purchase only one piece
of the license. For example, if you need rich gui components you will
spend about $1000 but you will get very powerful tools which can
significantly shorten development time - for both Windows and Web
platform (not to mention enormous end-user capabilities). The same (or
even cheaper) is with the refactoring or code generation tools etc.
Comparing such sums with the earnings of developer (or company) is
insignificant.

So, the question should not be if Access out of the box outperforms
Visual Studio (also out of the box) for some type of applications. I
agree it is probably true if we treat this question only theoretically
but in the real world developer should calculate the whole costs of
development. In the end everybody (at least in my opinion) realize that
the only meaningful cost is the development time.

Therefore I see the only reasonable argument in behalf of Access the
learning curve. Someone should consider if it's worth to spend more time
learning .NET and OO programming, and get the chance to compete also in
the enterprise applications market, or spend less time and stay limited
with the Access capabilities and obsolete programming language.

 

[Thomas]

I have two things to say to you: linked subforms and continuous forms.

Baz, I don't think this is an Access advantage. For example, look at
those tutorials:
http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html

It's fast to create (at least as fast as Access), it has more features
than Access etc.

This is only one approach - it's similar to Access' one (I don't like
any of them, though). If you need n-tiered application it's better to do
the dynamic grid creation. In both cases you can do it with VS out of
the box or you can buy some 3rd party components.

 

[(PeteCresswell)]

Per Thomas:

Dropping textboxes
and labels on the form,

In .NET does the developer still have to create a text box and
then separately create/align a label for that text box? Or do
they have an out-of-the-box textbox object whose label follows it
around like MS Access does?

 

[Baz]

Well I haven't got VS 2005 and I'm not likely to get it either (having
wasted a significant amount of my own money on upgrading from VS 6 to VS
2002/2003, and then concluding that it sucked so badly that I was simply not
interested in using it).

Nor am I impressed by a product which requires me to buy third-party add-ons
in order for it to be anywhere near usable.

 

[Thomas]

Baz, you can use free VS 2005 Express and don't buy any 3rd party
component if you don't want, and you can still produce i.e. continuous
forms with DataGridView component. This is not the best solution but
either is not worse than Access (for which there is no free version at
all).

IMO, a lot of 3rd party components *do* work very well - guys at
Developer Express, ComponentOne, Infragistic etc. really produce very
usable products. Serious developer should at least try them before judge
about their usability or quality. They are also very cheap comparing to
the price of developing only few percent of their features. Maybe it
sounds like advertising but I really just buy them and use them, and I
want to share good experience with other developers.


Regards,
Thomas

 

[Robert Morley]

(it's easier to ride bike than drive car, too).

Bad argument to make for me; I'm nearing 40, and I've never driven a car. I
use public transit for everything. About half my friends don't drive,
either, and my partner, who's a professional photographer, uses his bike as
his company vehicle without a problem.

As you say, form or report creating wizards are not of much use.

Actually, it wasn't me that said that, though for the most part, I agree.



Rob

 

[Robert Morley]

I think what Larry and I are trying to say is that for us, we find Access to
vastly outperform .NET in terms of development time.

That said, however, it's possible that .NET 2005 can do it, but I, at least,
haven't seen anything to prove that to me concretely, and I'm certainly not
about to spend money, and months or years worth of time porting my existing
business apps in the hopes that their might be some marginal gain to my
ability to develop applications faster. Even if we accept that development
is faster, the additional time/learning curve required easily outweighs any
advantage to .NET.

The performance of VB.NET also has yet to equal that of VB6/VBA, so that is
a consideration as well. The only way to get acceptable performance in many
cases is to use unmanaged code, and I have no ambitions to learn C++.


Rob

 

[Robert Morley]

You SERIOUSLY haven't looked at continuous forms and subforms if you think
any type of grid control holds a candle to them.


Rob

 

[Baz]

Yep, that sounds like advertising. As I said, I own VS 2003 Professional
and I consider it to have been a complete waste of money. I do not believe
that VS 2005 can be so much better that it is worth me spending any time on
it, and I'm certainly not going to waste any money buying add-ons for it.
I'd rather put my efforts into continuing my investigations into Delphi (not
that I see Delphi as a serious contender to Access either for database
applications, it's just that, for the odd occasion when I do something for
which I don't consider Access suitable, I'd like to have a serious and
current alternative to VB6).

 

[Thomas]

I'd like to hear some examples where continuous forms outperforms .NET
grids?


Regards,
Thomas

 

[Thomas]

I still don't know the reasons you were not satisfied with VS/.NET
(except that with learning time)?


Regards,
Thomas

 

[Thomas]

OK, I can partly agree with you as I prefer the bike, too. Maybe it's
really bad analogy. What about this one (note the "Compared with the
scroll..." sentence):

;-)


Regards,
Thomas

 

[Thomas]

I also think it's not good to use VS/.NET to port your existing
applications but it should be considered when thinking about the new ones.

But you can't argument advantages of one development tool just with
saying that it is better for certain people.

I have a proposal for trying to solve this dilemma: if you have one or
two days in the following month or two, we can imagine simple fictitious
business application (it can be also some usable problem which we can
sell then as a product, too ).
You can propose the half of virtual customer's demands, and I will
propose the other half. We can make together a portable database model
which will be the starting point for both of us. You will use Access
while I'll use VS/.NET to build the business application. When both of
us would be ready we can show the movie how did we build the application
and exchange application installer file.
We can use any additional tool and we'll compare the price of all used
tools (including Access and VS). The purpose of this "competition" is to
show both the speed of development and costs of software used. I think
this could be a good test for anyone watching this debate and asking
himself if it's worth to stick with .NET or rather with Access.
What do you think about it?

Regards,
Thomas

 

[Robert Morley]

The biggest example that comes to mind is the ability to create
"mini-forms". For example, I have a continuous subform for comments that
has a delete button on it, a few check boxes, and so forth. It's about a 1"
high form with a multi-line text box embedded within it. While in this
case, it's a plain text box, I have the option to make it an RTF editor or
anything else I might want. I'd seriously like to see a grid view that can
handle that kind of form design within it. Nothing even comes close that
I've ever seen. What's more, to do that kind of design work, I don't need
any additional knowledge of the control; my ability to create forms is all I
need to know.

But even looking at a one-line, grid style of form, there's all the
associated form events to consider, which most grids don't support, the
ability to put custom controls, images, command buttons, etc., into your
grid, the ability to disable fields (though some grids may do better in this
regard, since Access can only enable/disable the entire column at a
time...few grids support selective disabling, though, that I've seen).

It's these sorts of things that make me look at things like data grids as
the lesser form of continuous forms. And the ability to embed one form
within another is just as nice. I think you can get the same effect
with...was it panes they called it in .NET?...or using visual inheritance,
but I don't remember it being as easy as dragging and dropping one form on
top of another. I never really got that advanced on .NET, so I'd be content
to have it proven that it's just as easy in .NET as it is in Access.



Rob

 

[Robert Morley]

It's an interesting idea, but I seriously don't have the time these days.
If you'd asked me over the winter, I might've been able to do it. If
anybody else takes you up on that, though, I'd love to see the results.


Rob