dotnet windows forms vs. Access

  • Thread starter Thread starter PMK
  • Start date Start date
P

PMK

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?

Peter
 
I assume you are talking about VB.Net and Windows forms. I'm not sure why
you think that it's only for quick and dirty jobs, it's pretty powerful,
although a pig to learn. My dislike for VB.Net (and Visual Studio) is such
that I have recently been experimenting with Delphi, although I haven't gone
far enough yet to be able to recommend it.

If you are mainly using unbound forms, forget about Access. Using Access to
build unbound forms is like taking a sledgehammer to crack a nut. However,
I am curious as to the circumstances in which you feel you need to go
unbound. It is rarely necessary in my experience.
 
I assume you are talking about VB.Net and Windows forms.

Or C#.Net, etc., yes.
I'm not sure why
you think that it's only for quick and dirty jobs, it's pretty powerful

I didn't say only, and it's just a first impression - that is one of
the reasons I was asking for other opinions, but it is because you can
drag and drop so easily, including data connections - makes it easy to
knock off a simple application especially using datagrid type
controls, yet I am finding it unwieldy to deal with those very same
data controls - datasets, etc., manually.
although a pig to learn. My dislike for VB.Net (and Visual Studio) is such

What don't _you_ like about VB.net and VS?
that I have recently been experimenting with Delphi, although I haven't gone
far enough yet to be able to recommend it.

If you are mainly using unbound forms, forget about Access. Using Access to
build unbound forms is like taking a sledgehammer to crack a nut. However,
I am curious as to the circumstances in which you feel you need to go
unbound. It is rarely necessary in my experience.

I saw your comment about that elsewhere. I don't know why you feel
that bound forms is such a huge benefit of Access, but anyway, I use
unbound a lot primarily because I find it makes validation so much
easier and avoids the complexities of undoing an edit or reversing the
addition of a new record, particularly in a sub form.
 
PMK said:
On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"

I didn't say only, and it's just a first impression - that is one of
the reasons I was asking for other opinions, but it is because you can
drag and drop so easily, including data connections - makes it easy to
knock off a simple application especially using datagrid type
controls, yet I am finding it unwieldy to deal with those very same
data controls - datasets, etc., manually.

Hang on, you want to use unbound forms and yet you are trying to use
data-bound controls? Sounds like a contradiction to me. Data-bound
controls in Windows forms are indeed clumsy and cumbersome compared to
Access, and if that's what you want stick to Access. The datagrid is
absolutely hopeless when you compare it to what you can do in Access using
linked subforms and continuous forms.
What don't _you_ like about VB.net and VS?

It's a pig to learn. MS appears to have taken every concept in OO
programming known to mankind, and then some more that no-one had ever heard
of, and shoehorned them all into dotnet. It's an over-complex, overblown
smorgasbord of stuff that no-one needs. I hate the colossal dotnet
framework. And I hate the fact that MS killed off "classic" VB, the world's
most popular programming environment, in the face of fierce opposition from
hundreds of thousands of programmers.
I saw your comment about that elsewhere. I don't know why you feel
that bound forms is such a huge benefit of Access, but anyway, I use
unbound a lot primarily because I find it makes validation so much
easier and avoids the complexities of undoing an edit or reversing the
addition of a new record, particularly in a sub form.

Maybe you saw my comment about it elsewhere because you cross-posted!

Bound forms (and reports) are the ONLY benefit of Access. In particular,
Access' two most wonderful features are linked subforms and continuous
forms, both of which go out of the window when you use unbound forms. This
is NOT a criticism of Access, on the contrary, I would rarely use anything
but Access for database applications because nothing else even comes close
to it.

However, if I wanted to build something that consisted of all or mostly
unbound forms then I would even use VB.Net in preference to Access. In
order to achieve it's wonderful bound-forms capabilities Access comes with
all sorts of overheads, and if you don't want bound forms then you don't
need the overheads, as simple as that. If you want an analogy, building
lots of unbound forms in Access is like buying a 4x4 (or an SUV, if you
prefer) and never taking it out of the city. It works, but at a cost which
you don't need to incur.

How do unbound forms make validation easier? In a bound form you just stick
all your validation in the form's BeforeUpdate event procedure and you're
done. Undoing an edit? Press the Esc key (or click Undo on the menu).
Reversing the addition of a new record? Delete it. How else would you do
it? If you add a record through a bound form or an unbound form you still
need to delete it if it's a mistake. With a bound form you can do these
things without having to write a line of code, with unbound forms you have
to program all of these functions. How is that easier?

You are using unbound subforms? How, exactly?
 
I have done a lot of Access clients to SQL Server and find it very powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.

My experience is that Access takes a lot less programming effort (in
manhours) compared to vs.net to implement the same functionality. I find
this to be the big advantage of access. Some of the wizards in access are
quite powerful and will require a lot of manual coding in vs.net, especially
if you dont have a big library of vs. classes that you can reuse.

Access .adp client works fine when the client and the server are within the
same intranet. Vs.net provides the possibility to make powerful windows
clients communicating with sql server over the internet.

If you are familiar with access you can reuse a lot of your knowledge in
making access clients to sql server.

An access project (.adp file) is usually connected to the SQL Server at all
times while it is open. Each connection cause some load on the server. I
have never tried thousands of .adp clients connected to the same sql server,
but finally the load from idle connections could cause a problem.

Vs.net provides a wider set of mechanisms to tune the load on the server
(Disconnect when the connection is not needed) and provide better solutions
for large number of users.

Access usually requires the user to have an valid access user licence
(Office etc) and each client therefore has some cost. VS.net clients are
free once they are developed.

Unbound data entry forms is no problem with access. It requires some coding
in VBA, and it is not difficult to learn.

Regards

Tore
 
Maybe you saw my comment about it elsewhere because you cross-posted!

Comments on the topic at hand later, but I think in this case cross-
posting was warranted, as I wanted input from different groups of
users: Access and .net, most of whom probably don't read both groups.

Cross-posting, as opposed to multi-posting, is not inherently evil in
my book. However, I'm not going to drag this out - that's my only
comment I'm going to (cross)-post. ;-)

And the comment I saw about bound forms being a major advantage of
Access - I think it was yours - , was in a thread a few weeks ago but
I just came across.

Peter
 
Hang on, you want to use unbound forms and yet you are trying to use
data-bound controls? Sounds like a contradiction to me. Data-bound

I can see why. However, I was/am looking at alternatives to the way I
have been doing things.
controls in Windows forms are indeed clumsy and cumbersome compared to
Access, and if that's what you want stick to Access. The datagrid is
absolutely hopeless when you compare it to what you can do in Access using
linked subforms and continuous forms.

Bound forms (and reports) are the ONLY benefit of Access. In particular,
Access' two most wonderful features are linked subforms and continuous
forms, both of which go out of the window when you use unbound forms. This
is NOT a criticism of Access, on the contrary, I would rarely use anything
but Access for database applications because nothing else even comes close
to it.

However, if I wanted to build something that consisted of all or mostly
unbound forms then I would even use VB.Net in preference to Access. In
order to achieve it's wonderful bound-forms capabilities Access comes with
all sorts of overheads, and if you don't want bound forms then you don't
need the overheads, as simple as that. If you want an analogy, building
lots of unbound forms in Access is like buying a 4x4 (or an SUV, if you
prefer) and never taking it out of the city. It works, but at a cost which
you don't need to incur.

How do unbound forms make validation easier? In a bound form you just stick
all your validation in the form's BeforeUpdate event procedure and you're
done. Undoing an edit? Press the Esc key (or click Undo on the menu).
Reversing the addition of a new record? Delete it. How else would you do

That won't work with subforms, and with multiple subforms the coding
to deal with all the various errors a user could make in any of
multiple fields which will cause the record to save is extremely
difficult, time consuming and gives a less satisfying result than
unbound forms. I do admit to a fondness for unbound forms in general,
as I have found it is easier to create idiot proof forms that way.
it? If you add a record through a bound form or an unbound form you still
need to delete it if it's a mistake. With a bound form you can do these
things without having to write a line of code, with unbound forms you have
to program all of these functions. How is that easier?
You are using unbound subforms? How, exactly?

In Access, local temporary tables. With ADP it can get tricky.
Sometimes SQL temp tables, sometimes permanent tables that simply hold
the subform info on a temporary basis until it gets saved, or a
combination of both.

I appreciate your other comments and thoughts.

Peter
 
I have done a lot of Access clients to SQL Server and find it very powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.

Tore,

Can you give me a few examples?

Peter
 
If the topics/examples are limited in database applications, here mentions a
few in general:

- All sorts of web applications. MS Access app (*.mdb/*.accdb/*.adp) is
typical desktop client application. You cannot create web application with
it, either client side or server side. Do not mention Access DAP, it is
useless.

- Server/Client application(web app or win form app). .NET provide
complete set of infrastructure for server side development and client side
development (web client, win form, mobile device), which is used by VS
(VB.NET or C#), whilw Access is only client side desktop IDE/app.

- Even limited on Win form desktop app, with .NET you can easily develop
desktop app that uses all sorts of resources on the network (intranet and
the Internet) via Web Services/Remoting/WCF.

- Multiple tier enterprise system development...

As a development tool, VS is a lot richer that Access, as whole.
However, there is situation, your unique situation, where Access is the most
suitable tool to use. To make correct choice of development tool between VS
and Access, one need to know both Access and .NET (note, I say .NET, rather
than VS) well.
 
I've relied on Access supercharged with VB data marshalling since 1999.
Incredibly fast development, outstanding network performance (125 times
standard Access) coupled with 100% reliability.

Three years ago, I started transitioning to .NET. A lot of study and
experimentation has resulted in fast development, great performance and 100%
reliability. The end product looks better and is far more flexible. You can
do things in .NET that you can't do in MS Access using multi-threading.
Plus, with the extensive framework library, you have more to work with for
complex tasks.

There are some downsides. Plan on a long learning curve. VS 2005 is a real
performance pig (compared to VS 2003). Support from Microsoft is mediocre -
the little guys really try harder. All that aside, I'm happy with the
outcome and will not go back to Access.

An interesting comparison would be between .NET and Delphi 2007 for Win32.
I suspect the later might be a better choice.
 
The datagrid is
absolutely hopeless when you compare it to what you can do in Access using
linked subforms and continuous forms.

Can you please join some of the VB groups and make this argument...please?
<g> I've tried to on a couple of occasions (one of the larger debates was
just a week or two ago)...nobody seems to believe/understand me, and were
telling me how "unprofessional" Access apps look compared to VB apps.
Personally, I've yet to see anything in any version of VB that comes close
to the flexibility of Access' subform and continuous form capabilities.



Rob
 
In Access, local temporary tables. With ADP it can get tricky.
Sometimes SQL temp tables, sometimes permanent tables that simply hold
the subform info on a temporary basis until it gets saved, or a
combination of both.

I believe you can also use subforms using ADO recordsets bound to the
..Recordset property...but I do seem to remember a lot of crashiness and
other problems going that route, so I don't recommend it, necessarily.


Rob
 
Access usually requires the user to have an valid access user licence
(Office etc) and each client therefore has some cost. VS.net clients are
free once they are developed.

The one exception to this is that if you have the Office Developer's
edition, you can re-distribute the Access runtime freely, so this may not be
a problem.



Rob
 
- Server/Client application(web app or win form app). .NET provide
complete set of infrastructure for server side development and client side
development (web client, win form, mobile device), which is used by VS
(VB.NET or C#), whilw Access is only client side desktop IDE/app.

While it's far from complete, Access can provide server-side development for
SQL 2000 (or SQL 2005, if you're using Access 2007, I gather).
- Multiple tier enterprise system development...

No reason you can't do this in Access as well, though you'd need help from
some other development platform to create the middle tiers, most likely.
(Conceivably, you might be able to do it entirely in Access, but why you'd
want to is beyond me.)



Rob
 
Per Jim Rand:
Three years ago, I started transitioning to .NET. A lot of study and
experimentation has resulted in fast development

A few years back I was flirting with .NET.

But then I asked myself "What do I deliver to my clients that
makes me different from 10,000 highly-skilled, really-smart,
energetic people in Bangalore?"


I came up with three things:
------------------------------------------------------------
1) Really-RAD Development. I can turn on a dime and deliver
faster than any IT shop - anywhere.

My experience developing the same app in VB6 vs MS Access led
me to think that VB took three times the man hours.
Others have opined 5 or 6.

I don't see this as a dollar thing - because an offshore
shop might bill ten times the hours, but at only a twentieth
of the rate..... but it relates to the "turn on a dime" and
short delivery time aspects.

2) Minimal User Impact: The people I serve tend to be in
highly-competitive positions where they're already being
stretched to the max. They live and die by numbers
and if they falter, they're history.

Working with IT means they have to devote significant
man hours to filling out specs and meeting with programmer/
analysts - as opposed to just saying "Hey Pete.. how about..."
-------------------------------------------------------------



Questions - now that you're up to speed with .NET:
-------------------------------------------------------------
1) Do you feel that you can make midstream changes in .NET as
quickly as you could using MS Access?

2) What do you think your own ratio of MS Access man hours to
VB.NET man hours on the same application would be?
 
I came up with three things:
1) Really-RAD Development. I can turn on a dime and deliver
2) Minimal User Impact: The people I serve tend to be in

Uh...what happened to 3) ?
 
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.

Well, for un-bound forms, ms-access is the wrong tool. If you use un-bound
forms in ms-access, you get the WORST of both worlds. VB and vb.net has tons
of wizards and some nice data "binding" connection controls that really go a
long way to helping you build forms in vb.net.

In ms-access, the whole system is built around bound forms. So, the books,
the tweaking, the training, code examples, and yes even the wizards are all
built around a bound forms model.

Further, the form has 2 or maybe 3 times the number of events as compared to
vb forms. We have before update, after update, on insert.... the list is
HUGE compared to vb forms. and, we even have two events for when the form
loads

on-open - this event can be used to cancel the form load (a huge missing
feature in vb)

on-load - allows you to run setup code for the form...

So, environments like vb.net are DESIGNED around a un-bound forms mode, and
have HUGE number of wizards and features to deal with type of environment.

With access, we have a bound forms object model, and if you give that up,
you have no special wizards, no special tools, and simply are moving right
out of the environment of which ms-access was designed around. You get the
worst of both. Several here have stated that once you go the un-bound road,
then ms-access is just not the tool. You *can* do this in ms-access, but
IMHO, it just not worth it.

If you go un-bound forms, then vb.net going to run circles around ms-access.
However, with bound forms...we still kick vb.net butt in terms of building
data edit forms. I freely admit there is a tipping point in with the user
interface you need is better done in vb.net. However, for *most* business
line applications I write...ms-access is still the first choice..by a long
shot...


You going to have to give some examples as to why you found vb.net not you
cup of tea....
 
....NOBODY expects the Spanish Inquisition! Our chief weapon is
surprise...surprise and fear...fear and surprise.... Our two weapons are
fear and surprise...and ruthless efficiency.... Our *three* weapons are
fear, surprise, and ruthless efficiency...and an almost fanatical devotion
to the Pope.... Our *four*...no... *Amongst* our weapons....

So... How about: "Amongst my reasons are such diverse elemets as..." <g>

Cheers!
Fred Boer
 
...NOBODY expects the Spanish Inquisition!

or... given the off-topic posts that have been turning up here...

NOBODY expects the Spamish imposition!

John W. Vinson [MVP]
 
PMK said:
Tore,

Can you give me a few examples?

Peter

I use stored procedures on SQL Server a lot. They perform fast and are easy
to debug. If you dont know them look into SQL Server Help. I use stored
procedures to download data to the Access .adp client as well as for
inserts, updates and deletes on SQL Server. Once the stored procedure is
established on SQL Server, I will normally use ADO to run it from the Access
client. You can learn som ADO here: http://www.w3schools.com/ado/default.asp

My code in an Access forms module to call a stored procedure with parameters
could be something like this:

Dim CMD As New ADODB.Command, OwnerID As New ADODB.Parameter, YearID As New
ADODB.Parameter, _

AccountName As New ADODB.Parameter, RetAccountID As New ADODB.Parameter


CMD.ActiveConnection = CurrentProject.Connection

CMD.CommandType = adCmdStoredProc

CMD.CommandText = "MSP_InsertCustomerAccount" 'The name of the stored
procedure

Set OwnerID = CMD.CreateParameter("OwnerID", adInteger, adParamInput, ,
Forms!Menu.cboCompany)

CMD.Parameters.Append OwnerID

Set YearID = CMD.CreateParameter("YearID", adInteger, adParamInput, ,
Forms!Menu.cboFiscalYear)

CMD.Parameters.Append YearID

Set AccountName = CMD.CreateParameter("AccountName", adVarChar,
adParamInput, 100, Me.txtName)

CMD.Parameters.Append AccountName

Set RetAccountID = CMD.CreateParameter("AccountID", adInteger,
adParamOutput)

CMD.Parameters.Append RetAccountID

CMD.Execute

You can use a stored procedure as a recordsource of your form, but this
would make it a bound form. What you also could do is to download data to an
ADO recordset in your .adp client and use the recordset data to populate an
unbound form.

You call a stored procedure that returns some recordset. Sample code above
can be used for this. You have to add/change some lines of code:

DIM RS as new ADODB.Recordset

<Then lines as in example above>

Set RS = CMD.Execute in stead of CMD.Execute

If the stored procedure returns data they will go into the recordset RS, and
you can use the RS recordset data to update controls of your unbound forms.

Normally one would add some errorhandling as well.

Regards

Tore
 
Back
Top