Access or Visual Studio?

[Brian]

It probably won't surprise you to know that their are accomplished developers
like me who find the Access application development features difficult to use
and learn. Perhaps that's because I have done a couple of gigs where the users
in an organization had multiple home grown Access applications they wanted
converted to applications using MS SQL server. Not a pretty sight ;o)

I use Access all the time when I need a readily deployable database that doesn't
have multiple users, but I don't and won't make applications with it.

In which case, you are missing a great opportunity, and you are spending far
too much time and money developing database apps.

I have lots of real-world customers using real apps developed in Access,
some of them using an Access/Jet back-end, others using SQL Server. Many of
them would never have been willing/able to pay for the considerable
additional effort of building their apps with a less productive technology.

It is hardly the fault of Access that lots of apps have been built by people
with no technical skills and no idea how to design a database or an app.
It's pretty easy to swing a hammer, but you can't blame the tool if you hit
your thumb with it.

It does surprise me greatly to learn that "there are accomplished
developers...who find the Access application development features difficult
to use and learn." As someone who came to Access in the late nineties after
15 years developing database apps with all kinds of languages and
technologies, I found the concepts very readily understandable and the
necessary skills very readily transferable. I was doing VB/SQL Server work
at the time, but having blagged my way onto an Access job I found it pretty
straightforward to get to grips with.

 

[Sean Hederman]

As is yours, because it hasn't been through enough versions or major
upgrades yet to give real headaches. Microsoft's track record with other
products suggests that major upgrades always break something that used to
work. Of more concern, however, is the situation when the beast is, say,
5-10 years old and developers have to target an unpredictable
heterogeneous
population of framework versions and need to make their app work with all
of
them. It's a problem that Access developers struggle with (hence the OP's
comments), and I don't expect it to be any different with the dotnet
framework.

But one of the design goals of the .NET framework is to help resolve this
exact issue.

[Snip]

You attack a straw man. It was the OP who introduced the term
"freestanding" to describe a dotnet app, not me. I was merely pointing
out
the error in his interpretation.

In any case, there are lots of genuine binary programs on my computer.
Freestanding they may not be in an absolute sense, but, being real
binaries,
they are of a quite different nature to a dotnet app (or, indeed, an
Access
app or a VB6 app).

Actually most VB6 apps are genuine binary programs. The default compilation
option is native image not pcode. Anyway what's so holy about binary
programs? .NET winds up JITting the IL to binary, so once that's done once,
you effectively do have a binary app. I suggest you write some C++ code and
some C# code and compare the two final binaries. You'll find that the
machine instructions are very similar.

[Snip]

I've done it lots. Quite enjoy it, actually.

Good for you, I hate it. I like my code nicely commented and with good
semantic naming.

 

[Brian]

But one of the design goals of the .NET framework is to help resolve this
exact issue.

Setting goals is one thing, achieving them is quite another. I don't
suppose anyone ever started out with any product *intending* to cause
version issues.

Anyway what's so holy about binary
programs?

As someone who does much of his work in Access, it is highly unlikely that I
would claim there is anything holy about binaries, and I think you will find
that I indeed made no such claim. As I keep saying, I was simply
explaining/illustrating the OP's error in assuming that a dotnet app was in
some sense independent of a runtime environment and hence immune to version
problems.

Good for you, I hate it. I like my code nicely commented and with good
semantic naming.

Indeed, but there is a certain satisfaction in successfully completing a
detective mission. I just love problem solving, I'm a weirdo, I like
support work!

Don't get me wrong, I'm not totally anti dotnet, I can see that there is
merit in some of the things Microsoft has tried to achieve. However, for a
pure (Windows) database app of any size up to less-than-massive, I consider
that Access is so much more productive a development technology that it is
crazy, and possibly dishonest, to use anything else - and before anyone
starts screaming again about the limitations of the mdb file as a backend
database, let me say again, I KNOW, you hear me, I KNOW: Access apps can be
developed very satisfactorily indeed with a SQL Server backend, lotsa stored
procedures and so on, and this is what I often do.

This is not a criticism specifically of dotnet - I held the same opinion
about VB6 and predecessors - rather, it is a recognition of the special
qualities that Access brings to the table through it's status as a product
totally dedicated to one kind of app i.e. the Windows database app.

I myself invested in VS.Net as soon as it was out, and have several times
embarked on developing apps using it. However, on each occasion, I have got
so frustrated at the shortcomings, flaws and downright bugs I found that I
gave up and went back to VB6. Such as? I hear you asking. Well, here's
just one tiny, tiny example: the Windows Forms combo box control. A right
Friday afternoon job if ever I saw one. Why the hell doesn't it expose a
border style property? And why the hell doesn't it autocomplete (something
combo boxes have been doing since about Babbage's time)? OK, one of the
fantastic things about dotnet is that it's so easy to roll your own
controls, so you can get round cock-ups like this (anyone want an
autocompleting combo box with a border style property? I've got one
knocking around somewhere), but when you find and have to resolve something
like this every hour or so projects begin to look unfeasibly expensive.

OK, these things will get resolved (maybe they already have been, I haven't
looked at the thing for ages), but at the moment I'm pretty grumpy about
what seems to me to have been something of a waste of cash!