dotnet windows forms vs. Access

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

I use a third approach: forms bound to temp tables on C:.
--
PeteCresswell

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?
-------------------------------------------------------------
--
PeteCresswell

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) ?

Per Robert Morley:
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) ?

RCI.

Mea Culpa.
--
PeteCresswell

Per (PeteCresswell):
Uh...what happened to 3) ?

RCI.

Mea Culpa.


To clarify..... At first I had thought that my customers valued
the lower cost of minimal man hours - making the third item.

But as I wrote the post, I realized that I've come around to
believing that the lower cost isn't such a big thing with most of
them. Some of the hospitals, maybe... but the hardcore
financial/bond trader types that I serve 95% of the time, no. In
those cases I'm a miniscule slice out of a very large pie.
--
PeteCresswell

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....


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada