Future of access?

[Larry Linson]

I started to use ADO in 1998. I have
not been burned with ADO. I do not
know of anyone who has been burned
with ADO. I invite all ADO burnees
to state the nature of their burns and
the specific ADO causes of them
here in CDMA.

Am I wrong in recalling that you had stated here in CDMA that you had
abandoned use of ADO? Perhaps I am also wrong in recalling several who
posted about problems with ADO.

In my limited use of ADO, it wasn't ADO that burned us, but the poor design
practices of the original author (who, judging from the code style, was a
refugee from classic VB and didn't know much about database... like bound
forms, of which there were none; or primary keys, of which there were none
in the SQL database until I asked the DBA to assign one so I could bind a
form in a subform control), but I didn't find it any easier than doing
standard Access-Jet-ODBC-SQL Server and, with the quantities of data
involved in the application, performance was similar. In the applications I
worked on, IMNSHO, ADO was not worth the effort required to learn the
details of a new access method. But, other than that, my only real
irritation was that the criteria of a FIND was limited to a single
expression (situation handled by using an SQL SELECT statement instead).

Larry Linson
Microsoft Access MVP

 

[Larry Linson]

Well, I don't think ms-access ever was
an enterprise solution anyway.
However, do remember that 99% of
business in the USA is a small business.
So, while you can get all wound up about
big business, they don't represent any
sizeable factor here. So, while enterprise
solutions represents 1% of the business
market, ms-access will happily cover the
99% part.

In a "previous incarnation as a mainframer and minicomputer application
developer", I worked in the "enterprise solution" space. As an Access
developer, I worked with small and medium size organizations and with small
organizations in even larger enterprises which <SUR-PRIZE, SUR-PRIZE,
SUR-PRIZE> had requirements very similar to small and medium sized
businesses. I found the Access development business to be both more fun and
more profitable to me personally than being someone's employee in the
"enterprise world".

I realize that pre-dot-Net, the "enterprise solution space" was the only one
that Microsoft didn't "own", but am really surprised that when they went
after it with dot-Net, they seem to be paying so little attention to the
"little guys" who still need software and aren't satisfied with "canned
software" or "off-the-shelf applications".

Larry Linson
Microsoft Access MVP

 

[(PeteCresswell)]

Per Larry Linson:

I found the Access development business to be both more fun and
more profitable to me personally than being someone's employee in the
"enterprise world".

Couple years ago, I started dabbling in .NET because one of my clients had begun
a fairly-large project dedicated to replacing one of my MS Access apps with a
VB.NET analog and I had some vague notion of bringing myself up-to-date
toolwise.

After a short and unproductive struggle with the learning curve I sat down and
asked myself what I really had to offer.

My answer was that what I did best was develop applications for people who
needed them sooner than IT could deliver and/or didn't feel they had the time to
spend participating in an excrutiatingly-detailed requirements gathering
process. In the words of an esteemed former coworker: "I don't sell
programming, I sell happiness.".

My rule of thumb for VB6 development (based on developing a single small app
both ways) was that it took three times the manhours that the same project would
take in MS Access. Others - who probably have more experience - have said
it's closer to five or six.

I've never done a project both ways in Access and .NET; but from watching the
abovementioned project for three years I'd have to say that the factor for .NET
is at least ten...and maybe even twenty-something.

That pretty much ended my thoughts of adding .NET to my toolbox - that and the
realization that as a .NET developer I'd be entering an increasingly-commodified
enviromment - i.e. competing more and more with all those English-speaking,
hard-working, educated, intelligent, and diligent folks working for $14/day in
Bangalore...

 

[John]

Agree with your timings estimates more or less. problem is clients want
their applications with more sophisticated UIs and access has it limits. I
have myself tried to push it by using controls from dbditech, janusys,
totalaccess and so on but it seems that lately even these guys are loosing
interest and moving to .net.

 

[Sylvain Lafontaine]

I disagree with the notion the .NET is ten times harder then Access. You
are making a comparaison between someone who has many years of experience
with Access, who has probably probably bought many books on it (myself, I
count about 15 books on Access and ADO, I don't know what's the count for
you but I wouldn't bet 20$ that's only one or two) and probably spent many
months studying these books.

When I came from the world of UNIX, VAX assemblies and X-Windows, I don't
remember that learning Access was a particularly easy task. I spent months
trying to decipher the OnOpen, OnLoad and OnCurrent events and learn
idiosyncrasies such as the fact the queries are done before the OnOpen event
for forms but after it for reports, that if you set the record source inside
the OnOpen event, then the OnLoad event is directly called right after that
and no longer at the end of the OnOpen subroutine. When you see people like
Mary Chipman writing nearly a whole book only on the single subject of how
to use unbound forms to circumvent some of the limitations of Access could
hardly be see as a proof of its easiness. If I wanted to, I could add to
this list of *features* of Access until my retreat.

Seriously, I can't tell that Access was easy to learn when I see that I had
to buy 15 books on it and that there are many of its aspects that I still
don't know or are still stumping me. (For exemple, the Access 2002 version
of Litwin, Getz and Gunderloy covers 2 tomes and have more than 2300 pages.
Even with that, there are many aspects that they don't even cover.)

You are making a comparaison between Access and .NET for someone who has
spent many years studying and using Access but instead, you should make a
comparaison for someone who doesn't know Access or .NET at his starting
point; as this is the real situation for newcomers.

The real question is not to know if you have to buy 15 books on .NET and
spent the next months studying them; it is to know for a newcomer who has to
make the decision between buying 15 books on .NET or buying 15 books on
Access and spent the next months on one of these two, then what is his
(best) choice?

I seriously doubt that someone who will have to choose between studying
Access or .NET will find that .NET is ten times harder to learn. In fact, I
won't be surprised if he find that .NET might be, in fact, easier. But even
if his find .NET harder, the broader region covered by .NET - for exemple
the integration of images, the control of transactions, the connection with
the Internet and the absence of many of the illogical idiosyncrasies and
limitations of Access - should easily overcome this.

And before answering me, take a look at the number of books on Access,
Access & Client-Server and ADO that you have in your library.

 

[Rick Brandt]

I disagree with the notion the .NET is ten times harder then Access.

[big snip]

I don't think Pete said "ten times harder". He was estimating that
development times for similar functionality would be ten times as long in
dot-net.

Given the same task and asking a seasoned Access developer to turn out a
finished database app and a seasoned dot-net developer to do the same I
agree that the dot-net solution is going to take a LOT longer to put
together.

I offer no opinion on the superiority of either finished app over the other.
I believe each will have pros and cons, but it I were writing the check
there is no doubt that the dot-net bill is going to have LOTS more zeros in
it and that I am going to be waiting quite a bit longer before I write it.

 

[David Schofield]

I disagree with the notion the .NET is ten times harder then Access.

[big snip]

I don't think Pete said "ten times harder". He was estimating that
development times for similar functionality would be ten times as long in
dot-net.

Given the same task and asking a seasoned Access developer to turn out a
finished database app and a seasoned dot-net developer to do the same I
agree that the dot-net solution is going to take a LOT longer to put
together.

I agree, though this could change ...

I offer no opinion on the superiority of either finished app over the other.
I believe each will have pros and cons, but it I were writing the check
there is no doubt that the dot-net bill is going to have LOTS more zeros in
it and that I am going to be waiting quite a bit longer before I write it.

A big part of the ease of development is the sub-form and its wizards,
see for example Albert Kallal's encomium:
http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000005.html
If applications don't need subforms they probably can be coded as
easily in other systems.
What puzzles me is why no-one else has developed anything like this
for other systems as some of the grids and controls must have involved
as much development time.

The main drawback of Access (as a FE) is that it the end product isn't
deployable in the way people now expect. Personally I use it for
back-office systems such as data maintenance and reporting rather than
for general users.
David

 

[Mike Painter]

John wrote:
Three years after my Access package was replaced at the local university
pharmacy they were still using parts of it to do things *mandated* by the
government. The first year was a nightmare for them because of features
missing and the awkward implimentation of some needed functions.

The lab watched, then refused to move.

 

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in

I disagree with the notion the .NET is ten times harder then
Access.

Well, it's a good thing Pete didn't say that -- he said development
takes 10 times as *long*, not that it is 10X harder.

 

[(PeteCresswell)]

I seriously doubt that someone who will have to choose between studying
Access or .NET will find that .NET is ten times harder to learn.

I wouldn't challenge that - especially given the number of books/courses
available today.

What I was saying was that developing a system via .NET would take at least ten
times the manhours that it would in MS Access.

I don't have a whole lot to base that on except:

1) The VB6 ratio (let's say 3:1 absolute minimum) seems pretty solid to me and
everybody I've worked with that does .NET says it takes more manhours than
VB6... and the guy who said it was closer to 5:1 has probably forgotten more
than I'll ever know.... so 3:1 is probably on the low side.

2) A smallish project that I delivered for less that $75k was rewritten by the
client's IT as net-centric (although I cannot swear that they used .NET
exclusively) at a cost of a little over three million dollars. Exactly,
precisely the same functionality - except that it was presented via a Browser
interface.

3) The project that I alluded to in the original post was delivered by Yours
Truly working solo over a period of five years for a cost of a little under
$225,000. Last time I checked, the .NET replacement had 46 people working on
it and had racked up over 23 million dollars.... and should be delivered
sometime Real Soon Now....like by the end of this year. Probably a good 30%
more functionality....maybe fifty.... but not two hundred.


Clearly, projects with many people working on them are less efficient that solo
endeavours - if only because of communication sippage - so the 23 mil comparison
is exaggerated. But by how much? A hundred times? Don't think so....

Also, I take your point that I as an (ahem...) vastly-experienced MS Access
developer can churn out code faster than I could as a .NET newbie.

I've even heard a guy that I brought up in MS Access and who is now a journeyman
..NET programmer say that he could get a screen working in .NET in "just about
the same time as MS Access.".

But I've got to wonder:

1) Just at the screen level, little time-consuming tasks like having to position
each control's label...

2) Having to write a couple pages of code for every combo box to implement
AutoScrolling and AfterUpdate. Yes, they can inherit classes.... but somebody
has to develop those and they have to be made specific to the immediate
situation.

3) And the biggie: having to do the back end on an SQL database - and therefore
develop all those stored procedures which I absolutely positively *know* take at
least 10 times the manhours per procedure as a DAO query done via the visual-UI
query designer.... maybe more.

4) Not to mention having to write the code behind all those datasources...

5) Crystal reports take longer to develop than MS Access reports...period.


I really was entertaining the idea of developing a .NET prototype project - sort
of a synthesis of the most common MS Access projects I do: Home screen, bunch
of parent/child screens for various tables, Admin screen, Report picklist
screen....

I figured that if I could come up with a template that would allow me to churn
out a .NET project in three times the manhours that it took for an MS Access
project, a certain number of users would go for that just to say they have the
latest-and-greatest.

Maybe when my current batch of clients have had their way with me, I'll revisit
that little fantasy.

But I'm still back to: "What do I do that the boys and girls in Bangalore can't
do for $14.00 per day?" And part of the answer is "Develop stuff really
fast." and "Turn on a dime when the client changes their mind or gets a new
idea."

 

[Larry Linson]

Strange, I don't remember any great amount of struggle being required to get
on board with Access, and certainly nowhere near 15 books. I remember Access
2 had a very nice set of manuals, and everything in those manuals was
included in the online help (and, just for the record, it was easy to use
the 16-bit WinHelp and easy to search for and find topics). As I recall, I
had one "general" book (Prague and Irwin's "Access Bible"), one "advanced"
book (The "Access 2 Developer's Handbook" by Litwin, Getz, et al), the
Access 2 manuals, and Help.

I thought it the very easiest programming tool I had ever had to learn, and
I've learned a lot of them since starting in the computer business in 1958.
(Yep, only three years from my golden anniversary.)

If you weren't familiar with "handling events", I suppose, it could have
been a steeper learning curve -- something of a change of view as to how an
application should operate. Even with a long background in mainframe POLs,
though, the idea of responding to events also did not seem a real stretch
when I first encountered it in the minicomputer world.

The object-oriented (or object-obsessed?) world view of dot Net languages,
however, does take some serious changes of view. Everything's an object,
even pieces of data that only used to represent a reservation of storage. I
don't find it at all difficult to imagine doing exactly the same application
in dot Net (whether VB.NET, C#, or COBOL.NET) taking ten times as long as
doing it in Access, even if both are done by "whizzes" in the respective
development environments -- there are soooo many things that Access does
_for_ you that you have to do for yourself, or find something suitable in
some library, or purchase a third-party control to accomplish in dot Net..

That's not to say that dot Net does not have it's place -- the
code-intensive, server-situation, web-based distributed enterprise-level
application. Unfortunately, that's not the kind of application that most of
us do in Access because it is not what our employers or clients need.

Larry Linson
Microsoft Access MVP

 

[David W. Fenton]

[]

If you weren't familiar with "handling events", I suppose, it
could have been a steeper learning curve -- something of a change
of view as to how an application should operate. Even with a long
background in mainframe POLs, though, the idea of responding to
events also did not seem a real stretch when I first encountered
it in the minicomputer world.

I found events quite puzzling, coming from a sequential, Paradox
programming experience. But I sure loved the engine-level
referential integrity. Cascading deletes were a dream!

I also had trouble with DAO, but that was as much because SQL's
set-oriented thinking did not come naturally to me, and took a while
for me to grasp.

[]

That's not to say that dot Net does not have it's place -- the
code-intensive, server-situation, web-based distributed
enterprise-level application. Unfortunately, that's not the kind
of application that most of us do in Access because it is not what
our employers or clients need.

I think there's a bait and switch going on, in that .NET seems to be
for making distributed (i.e., NETworked) apps, and, specifically,
web-based, browser-hosted apps, while it's being sold as a
multi-purpose development tool for desktop apps. The two
orientations seem to me to be at odds with each other.

 

[Mike Painter]

I found events quite puzzling, coming from a sequential, Paradox
programming experience. But I sure loved the engine-level
referential integrity. Cascading deletes were a dream!

I came from Revelation (Pick based). while it was procedural about 99% of
anything on a form had a ton of "events" attached to it so getting real
events was nice.

It was much easier to move from Rev to Access than from Rev to the very poor
implimentation of Rev in Windows.

Not being able to enter a key in a text box and have it pop the record was a
pain for a while, I still think it should work that way.

Not having the previous record, and the original of the current record
exposed was and is a real pain.

Maybe in a few more years MSFT Basic will catch up to Pick basic in string
handling.
(Although finally having Split and Replace make some of the others much
easier to code.)

 

[Tony Toews]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote:

When you see people like
Mary Chipman writing nearly a whole book only on the single subject of how
to use unbound forms to circumvent some of the limitations of Access could
hardly be see as a proof of its easiness. If I wanted to, I could add to
this list of *features* of Access until my retreat.

I don't know why you'd want to use unbound forms except in some
special circumstances. Granted I'd like to see independent combo
boxes on continuous/sub forms and independent unbound fields but other
than that bound forms work very well for me.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Larry Linson]

If you went to unbound forms, why would you bother to use Access -- why not
move on to classic VB? Classic VB pretty much _had_ to use unbound forms
because its binding was not nearly as good as Access' binding. The big
advantage of using Access over VB for database development was the richer
event model for database.

Most people I know used some unbound forms when they were just starting
because they couldn't easily figure out how to do what they wanted. Some
went on to "grok the Access way -- bound forms" and rarely, if ever, use
unbound forms any more; but the use of unbound forms kept others from
learning much more about Access, so they never really learned Access and,
thus, never were able to enjoy the advantages that Access and bound forms
gave them in development time and effort.

Larry Linson
Microsoft Access MVP

 

[(PeteCresswell)]

Per Tony Toews:

I don't know why you'd want to use unbound forms except in some
special circumstances.

My theory is that unbound forms help to make the app more bulletproof.

Instead of somebody sitting on a record - and maybe turning off their PC or
something, the app just hits the DB for a fraction of a second to populate the
form and then it's out of the back end.

For me they also facilitate "Browse" and "Edit" modes with "Save" and "Cancel"
by enabling the programmer to do quite a bit more cross-checking/validating
before anything goes out to the back end.

Maybe this is all BS - but I've been doing unbound forms for so long that
they're second nature (i.e. quick and easy to clone...) whereas every time I've
tried reverting to bound forms the users have come up with a requirement that
broke my little scheme. OTOH, maybe I just haven't developed the skill set
needed to deal with some of those situations in bound forms...

 

[(PeteCresswell)]

Per (PeteCresswell):

but I've been doing unbound forms for so long that

I think I got off on the unbound forms tangent developing for SQL Server back
ends. They seemed to fit more conveniently with the idea of stored procedures
to deliver the data - often via multi-file ADO recordsets so we'd only have one
round-trip to the server to load a screen with, say, seven child tables on it.

 

[lylefair]

Am I wrong in recalling that you had stated here in CDMA that you had
abandoned use of ADO? Perhaps I am also wrong in recalling several who
posted about problems with ADO.

Yes, you are wrong. Perhaps, you are thinking about my posts about ADPs.

 

[(PeteCresswell)]

Per Larry Linson:

If you went to unbound forms, why would you bother to use Access -- why not
move on to classic VB?

Now that you mention it, VB was another driving force in my choice. At the
time, I thought that I might as well write this stuff as much like a VB app as
possible just so I can transition myself if VB work comes my way.

Various clients wanted MS Access because of:

1) The notion that they could take over maintainence of the app once I was done.
Fallacious, IMHO - but that was their perception.

2) It's reputation for fast turnaround/delievery.

3) Back in the End User Support days, MS Access was a sort of "official" tool
for end-user projects - as opposed to VB.



Personally, if a client wants cheap and fast I'd still use Access because the
one trial project I did both ways took three times the hours to do in VB as it
did in Access - and the analysis had already been done. Others who have
probably forgotten more than I'll ever know have said the factor is more like
five or six.

The querybuilder, reports, text boxes with the attached labels that follow them
around, subforms, ComboBoxes' AfterUpdate().... and so-forth.
Little things that add up manhourwise.

Finally, because Access what I do. They could probably find a more skilled VB
developer for less dollars per hour.

 

[Tony Toews]

My theory is that unbound forms help to make the app more bulletproof.

Instead of somebody sitting on a record - and maybe turning off their PC or
something, the app just hits the DB for a fraction of a second to populate the
form and then it's out of the back end.

Whereas I've been on site at one client for at least three or four
power failures and they've never had a corruption. I'm sure at least
four or six users were in adding or editing a record each time the
power went out.

Note that the switches and servers were on UPS..

I'm much more concerned with that millisecond of time when they do the
update. And there's no real difference between bound and unbound
forms for that time duration.

For me they also facilitate "Browse" and "Edit" modes with "Save" and "Cancel"
by enabling the programmer to do quite a bit more cross-checking/validating
before anything goes out to the back end.

Yeah but that's not a bid deal to me.

Maybe this is all BS - but I've been doing unbound forms for so long that
they're second nature (i.e. quick and easy to clone...) whereas every time I've
tried reverting to bound forms the users have come up with a requirement that
broke my little scheme. OTOH, maybe I just haven't developed the skill set
needed to deal with some of those situations in bound forms...

<smile> Or maybe you just think sideways too much.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm