C#, ADO.NET vs. MS-Access

[MS]

OK, now, I've climbed far enough up the learning curve to be about where I
was with Access in building data-driven Windows forms but I've seen no
advantage over the old way. Maybe finer-grained security but DLL-hell was
not a real problem before - just give 'em a new MDE and a macro to link the
tables up again. Distribution wasn't a real problem if you used Access
runtime. Getting at the nuts and bolts could always be done with VBA. With
a decent back-end, neither capacity nor performance seemed to be any
problem. Why then, was my past year of learning .NET worth the trouble (as
far as Windows forms apps are concerned)?

[Jeroen Mostert]

Mr. Arnold wrote:

>
"MS" <asdf@asdfwrote in message
news:ej****************@TK2MSFTNGP02.phx.gbl...

>OK, now, I've climbed far enough up the learning curve to be about
where I was with Access in building data-driven Windows forms but I've
seen no advantage over the old way.

<snip>

You trying to compare .Net and ADO.Net with Access and VBA, well what
can be said about it but ridiculous. :)

I have to disagree here. There is certainly a valid comparison between
Access/VBA for desktop database solutions versus Access/ADO.NET or
MSSQL/ADO.NET. Just because ADO.NET is vastly more powerful doesn't mean
it's necessarily superior to what the OP's used to, for the applications the
OP's been writing.

IMO, the biggest win in investing in .NET and ADO.NET is that you have a
much better basis for scaling. With Access/VBA, this is just painful. Once
you outgrow your Access database and have to migrate to SQL Server and
client apps (and this almost always happens) you're in for a lot of
rewriting. If your client code is already written in .NET and using ADO.NET,
this is greatly simplified.

--
J.

[Mr. Arnold]

"Jeroen Mostert" <jm******@xs4all.nlwrote in message
news:47***********************@news.xs4all.nl...

Mr. Arnold wrote:

>>
"MS" <asdf@asdfwrote in message
news:ej****************@TK2MSFTNGP02.phx.gbl...

>>OK, now, I've climbed far enough up the learning curve to be about where
I was with Access in building data-driven Windows forms but I've seen no
advantage over the old way.

<snip>

>You trying to compare .Net and ADO.Net with Access and VBA, well what can
be said about it but ridiculous. :)

I have to disagree here. There is certainly a valid comparison between
Access/VBA for desktop database solutions versus Access/ADO.NET or
MSSQL/ADO.NET. Just because ADO.NET is vastly more powerful doesn't mean
it's necessarily superior to what the OP's used to, for the applications
the OP's been writing.

I have used Access, and I have used VBA. It's time has come and gone, mostly
gone. And no one in their right mind in making a serious desktop solution
would even consider it in today's environment IMHO.

[Mr. Arnold]

"Jeroen Mostert" <jm******@xs4all.nlwrote in message
news:47***********************@news.xs4all.nl...

Mr. Arnold wrote:

>>
"Jeroen Mostert" <jm******@xs4all.nlwrote in message
news:47***********************@news.xs4all.nl.. .

>>Mr. Arnold wrote:

"MS" <asdf@asdfwrote in message
news:ej****************@TK2MSFTNGP02.phx.gbl. ..
OK, now, I've climbed far enough up the learning curve to be about
where I was with Access in building data-driven Windows forms but I've
seen no advantage over the old way.
<snip>
You trying to compare .Net and ADO.Net with Access and VBA, well what
can be said about it but ridiculous. :)

I have to disagree here. There is certainly a valid comparison between
Access/VBA for desktop database solutions versus Access/ADO.NET or
MSSQL/ADO.NET. Just because ADO.NET is vastly more powerful doesn't mean
it's necessarily superior to what the OP's used to, for the applications
the OP's been writing.

I have used Access, and I have used VBA.

So have I.

>It's time has come and gone, mostly gone.

Ha, wouldn't you like to think that. Now is the time of the maintaining,
where a stroke of the keyboard will unleash the power of the sickening!
Much money is still to be earned in uncomfortable support and migration
jobs.

Migration is one thing? Support of old technology is another, something most
don't want to be bothered with it.

>

>And no one in their right mind in making a serious desktop solution would
even consider it in today's environment IMHO.

I didn't say that. The OP asked for the specific technological benefits
over "the old way", and I just pointed out that the benefits ADO.NET
offered just may not be that relevant for what he's developing, so calling
any comparison "ridiculous" is a bit much.

What is he developing? The only thing he could be doing is maintenance at
this point and time as no one is moving forward with the outdated
technology.

The point is not to become stagnated, which I have not done and will never
do since I started in IT in 1971.

Maybe, the op has some kind of common sense and will not let himself become
stuck in some kind of security blanket of old technology quicksand.

There is money in old technology such as mainframe solutions, that are still
active and I get offers to contract them. But I don't go backwards or stay
stagnant with old technology.

Mama didn't raise no fools.

[Jeroen Mostert]

Mr. Arnold wrote:
<snip>

There is money in old technology such as mainframe solutions, that are
still active and I get offers to contract them. But I don't go
backwards or stay stagnant with old technology.

And good for you. But believe me when I say that plenty of people will still
get jobs the coming years by maintaining and slightly extending those creaky
old Access solutions that penny-wise management just doesn't have the time
and money for to upgrade to shiny new technology. Just as many will get jobs
rewriting *everything* to shiny new technology, of course.

Mama didn't raise no fools.

Yeah, but I think managers are actually grown somewhere, not raised.

--
J.

[Vinnie the Rat]

On Feb 21, 6:59*am, Jeroen Mostert <[e-mail]:

Mr. Arnold wrote:

<snip>There is money in old technology such as mainframe solutions, thatare

still active and I get offers to contract them. *But I don't go
backwards or stay stagnant with old technology.

And good for you. But believe me when I say that plenty of people will still
get jobs the coming years by maintaining and slightly extending those creaky
old Access solutions that penny-wise management just doesn't have the time
and money for to upgrade to shiny new technology. Just as many will get jobs
rewriting *everything* to shiny new technology, of course.

Mama didn't raise no fools.

Yeah, but I think managers are actually grown somewhere, not raised.

--

Due to apparent time zone differences, I missed replying, not that
this "OP" is put off by the responses here and just to be clear, I'm
no newbie, either. Maybe what I need are some specifics in which to
frame the kind of responses I was seeking: Windows forms
applications, 100 - 150 users, shared access, databases of less than
1gb - 500mb - that's my environment and it's not been too bad using
MDE front ends with linked tables from a SQL Server database. Other
than the fact that MS is stepping away from Jet, just what (an example
or two is what I'm after) would I get from ADO.Net?