dotnet windows forms vs. Access

[Robert Morley]

That sounds like something Bush would say.


Rob

 

[Baz]

On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"

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.

What will not work with subforms? You've lost me.

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

Ohhhhh I begin to see where you are coming from. You're talking about
entering records in both a main form and a subform as a single logical
transaction. Not a requirement I have often encountered, although I have
needed to do it once or twice. Would be interesting to hear more about your
circumstances.

Presumably when you use local tables in an mdb, temporary tables in SQL
Server or whatever, you are binding forms to them? Otherwise why use tables
at all as your "temporary" repository?

 

[Baz]

Hi Robert,

Yes, I had a good go at doing that when the form's Recordset property was
first exposed to use, it was unusable, Access crashed all over the place.

 

[Baz]

Sorry Robert, I've got into arguments before with the dotnet-heads, it's a
waste of time and energy. There's none so blind as those who will not see.

 

[Baz]

Right on Pete, absolutely right.

Per Jim Rand:

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?

 

[Baz]

LOL!

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

 

[PMK]

Tore,

I am familiar with and use stored procedures. I meant examples of what
you mean by: "Vs.net provides a lot more functionality for windows
clients than access."

Peter

 

[PMK]

Ohhhhh I begin to see where you are coming from. You're talking about
entering records in both a main form and a subform as a single logical
transaction. Not a requirement I have often encountered, although I have

I'm not sure how you could avoid it other than (off the top of my
head) putting the main form data onto a subform also. Anyway, in my
situation users enter main form data and then go on to enter subform
data. That is in a perfect world. They may try to enter the subform
data first which sets off an unhappy chain of events in bound forms.

Yes these (sub)forms are bound also, but not to the 'permanent' tables
so nothing is entered into the db until the operator (and my
validation code) has clearly indicated that the data is cleared to be
processed. BTW, deletes are often not treated casually and may only
allowed by certain operators and even then tracked so the
unintentional saving of a record is not a trivial event.

I may also deal with this in a variety of other ways, including hiding
subforms until essential data is entered. Sometimes that works well -
sometimes not. These strategies can't be divorced from the real world
situation. I mean you have to put yourself in the data entry person's
shoes and tailor the form to their skills, needs and working patterns
and also anticipate the kind of mistakes they will probably make and
figure out the best way to recover from them.

needed to do it once or twice. Would be interesting to hear more about your
circumstances.

Maybe it is just a difference in style. I did not look for ways to
avoid this. It (unbound forms) seemed the best way of the various
alternatives to make the users the most productive and avoid data
entry errors and frustrations, particularly as my users are mostly
not native English speakers nor particularly computer savvy
-suggesting using the ESC key to reverse a data entry would just be a
waste of time as would be suggesting using the built in Access menus,
which I do not expose to them. I don't regret it - the system works
well, is easy for them, and in fact data entry errors and service
calls were few (I am thinking of the app with the heaviest use of
unbound forms).

Presumably when you use local tables in an mdb, temporary tables in SQL
Server or whatever, you are binding forms to them? Otherwise why use tables
at all as your "temporary" repository?

Yes, the subforms are always bound to temporary tables - either Access
or MS SQL temp tables or tables used to store the data temporarily
until it is written to the main tables. The main form may or may not
be. I've also tried binding to recordsets with mixed results. For me,
an added advantage of using tables over code is it is easier that way
for me to go back a year or two or three later and quickly refresh
myself as to what the logic in that part of the application is.

I find all the comments about my approach being the worst of two
worlds interesting. To me that implies I not only wasted a lot of time
but also produced an inferior product. Yet I've taken on jobs that
others have tried and failed to complete and produced a result that
has satisfied the requirements of the clients which is demonstrated
not only in their initial remarks and experiences, but by the fact
they by and large have continued to use and rely on the apps for years
and years.

In fact, other than perhaps a slicker look using VB, I can't see how
the apps could be better! And with the last and most complex one I had
a lot of time to mull over that, as I worked as I.T. Admin for that
client for 5 years after creating the app, did some tweaking on it in
that time, but never had cause to question the underlying
construction, including form strategies.

It might be the worst of one or even two worlds for a completely
different applcation though - which could be said of almost any
approach. ;-)

Peter

 

[PMK]

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

Actually my question (it's in the subject line) regards windows forms
only.

Do not mention Access DAP, it is useless.

Do you mean ADP? If so, sorry but that statement is not only wrong,
it's silly.If you want to defend it, then how about some facts and not
just a 'don't mention it'?

It's not useless to my clients and one in particular that has been
very dependent on an ADP I did for them seven years ago that has given
them a huge competitive edge on their competition. If that app stops
working, then they stop working and neither has happened other than
from hardware failures.

Now DAP, whatever that is, may indeed be useless but you have to tell
us what is is first. ;-).

Peter

 

[Rick Brandt]

Do you mean ADP? If so, sorry but that statement is not only wrong,
it's silly.If you want to defend it, then how about some facts and not
just a 'don't mention it'?

It's not useless to my clients and one in particular that has been
very dependent on an ADP I did for them seven years ago that has given
them a huge competitive edge on their competition. If that app stops
working, then they stop working and neither has happened other than
from hardware failures.

Now DAP, whatever that is, may indeed be useless but you have to tell
us what is is first. ;-).

Peter

An HTML form produced from Access. The fact that you've never heard of them is
a pretty good indicator of how useful they are.

 

[Baz]

I'm not sure how you could avoid it other than (off the top of my
head) putting the main form data onto a subform also. Anyway, in my
situation users enter main form data and then go on to enter subform
data. That is in a perfect world. They may try to enter the subform
data first which sets off an unhappy chain of events in bound forms.

The way I stop subform records being entered when there's no parent record
is very simple: in the parent form's Current event, one line of code
disables the subform control if the parent form's NewRecord property is
True, and one line of code in the parent's AfterInsert event enables the
subform control. Thus it is impossible to enter data into the subform
unless the parent record has first been entered and saved.

Yes these (sub)forms are bound also, but not to the 'permanent' tables
so nothing is entered into the db until the operator (and my
validation code) has clearly indicated that the data is cleared to be
processed. BTW, deletes are often not treated casually and may only
allowed by certain operators and even then tracked so the
unintentional saving of a record is not a trivial event.

You either validate the data in the form, or you validate the data in your
"temporary" tables. Either way, if it passes validation it's gonna finish
up in the permanent tables, and if it was entered in error it's gonna have
to be deleted. I don't see how the "temporary" tables help at all.

If you want the operator to always explicitly request a save (i.e. you want
to stop Access' default behaviour of automatically saving the record when,
say, closing the form or cycling to another record) then it's very easy to
add, say, a Save button, and to have the BeforeUpdate event cancel itself
unless it was initiated by the Save button.

I may also deal with this in a variety of other ways, including hiding
subforms until essential data is entered. Sometimes that works well -
sometimes not. These strategies can't be divorced from the real world
situation. I mean you have to put yourself in the data entry person's
shoes and tailor the form to their skills, needs and working patterns
and also anticipate the kind of mistakes they will probably make and
figure out the best way to recover from them.

Wizard-style data entry (which normally would involve unbound forms) is good
way of handling repetitive data entry tasks which need to be done quickly
and accurately. However, I would normally also have a full-blown bound form
to enquire upon the data, and for more sophisticated users to perform more
complex data entry which doesn't follow the path that the wiz takes.
Although, of course, this is all highly dependent upon the business
requirements.

Maybe it is just a difference in style. I did not look for ways to
avoid this. It (unbound forms) seemed the best way of the various
alternatives to make the users the most productive and avoid data
entry errors and frustrations, particularly as my users are mostly
not native English speakers nor particularly computer savvy
-suggesting using the ESC key to reverse a data entry would just be a
waste of time as would be suggesting using the built in Access menus,
which I do not expose to them. I don't regret it - the system works
well, is easy for them, and in fact data entry errors and service
calls were few (I am thinking of the app with the heaviest use of
unbound forms).

It's very easy to put a great big "Undo" button on a form, and I often do.
I never expose built-in Access menus either, but it's very easy to add built
in Access menu options (such as Undo) to your own custom menus.

I'm not suggesting you should regret using unbound forms, that wasn't the
point I started off trying to make. My point is that if you are always or
mostly using unbound forms then Access is the wrong tool for the job.

Yes, the subforms are always bound to temporary tables - either Access
or MS SQL temp tables or tables used to store the data temporarily
until it is written to the main tables. The main form may or may not
be. I've also tried binding to recordsets with mixed results. For me,
an added advantage of using tables over code is it is easier that way
for me to go back a year or two or three later and quickly refresh
myself as to what the logic in that part of the application is.

So you ARE using bound forms!

I find all the comments about my approach being the worst of two
worlds interesting.

But it seems that your approach is not what you said it was: you ARE using
bound forms!

In fact, other than perhaps a slicker look using VB, I can't see how
the apps could be better! And with the last and most complex one I had
a lot of time to mull over that, as I worked as I.T. Admin for that
client for 5 years after creating the app, did some tweaking on it in
that time, but never had cause to question the underlying
construction, including form strategies.

So why are you even considering changing to dotnet? You said above that
your subforms are always bound to tables. Whether they are "temporary"
tables matters not a jot: by using bound subforms you are using powerful
Access features which are not available in dotnet (or indeed any other
development environment that I am aware of).

 

[Baz]

Do you mean ADP? If so, sorry but that statement is not only wrong,
it's silly.If you want to defend it, then how about some facts and not
just a 'don't mention it'?

He means what he said: DAP = Data Access Pages. If you have Access 2000, or
2002, or 2003, look it up in Help. Or click on the "Pages" button at the
left-hand side of the database window and see what that does for you
(although he's right, they ARE useless).

Some people do believe that ADP's are also useless, and although I don't
agree (having done lot of them myself), there's a strong argument that, if
not useless, they are at least pointless. Before
ADP's were invented in Access 2000, we already had ODBC linked tables which
were, and still are, a very good way of using Access with SQL Server, or
indeed ANY database for which you can find ODBC drivers. There might have
been some point to ADP's if Microsoft had carried through it's plan of
dropping Jet and migrating wholly to SQL Server but, in typical Microsoft
fashion, the plan was short-lived. The new accdb format with revamped Jet
and DAO is the new way forward, with good ol' ODBC linked tables the
preferred way of using server database engines. Infuriatingly for those of
us who've made a significant investment in them, ADP's are on the road to
nowhere.

 

[PMK]

An HTML form produced from Access. The fact that you've never heard of them is
a pretty good indicator of how useful they are.

Oh, now I remember them - I think I devoted about 8 minutes to them
once. Man,that was ages ago. I mean, that is just trivia now. ;-)

My excuse for the rant is I don't think I ever saw the DAP acronym,
they would be off topic so didn't expect that they would be mentioned,
and with all the discussion of ADP made a wrong assumption.
Nevertheless, my bad and apologies to the OP.

Peter

 

[Jim Rand]

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?

Yes.

2) What do you think your own ratio of MS Access man hours to
VB.NET man hours on the same application would be?

The ratio is 1.3. That is, 100 hours in Access versus 130 hours in C#.

By the way, I use C#.

Jim

 

[Robert Morley]

Hehehe. In my case, it was actually the VB6 group, but close enough.


Rob

 

[Baz]

I actually like VB6 a lot better than dotnet, but the similar issues exist
when compared with Access!

 

[aaron.kempf]

yes, Access Data Projects are a much better solution than .NET forms

plug and play
easy development

it's really really simple

FILE, NEW, PROJECT EXISTING DATA

 

[aaron.kempf]

What don't i like about VS.net?

It's slow
in development and execution


it's not database-centric
it's not as powerful as crystal reports

 

[aaron.kempf]

local tables are not a feature kid; I mean are you ****ing retarded?


seriously bud

if you need a 'local table' in ADP then you need to learn how to use
TSQL
I mean get real bud

 

[DAVID]

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.

You have to buy the tools. Then the distribution is free.
Except that there has been a free version of VS for a couple
of years now, and the free version of the Access redistributable
(for Access 2007) is not available yet.

(david)