C#, ADO.NET vs. MS-Access

  • Thread starter Thread starter MS
  • Start date Start date
M

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)?
 
MS said:
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)?
Click to expand...

ADO.NET provides many database providers like MS SQL Server, Access,
Oracle, MySql and many other database providers seamlessly.

ADO.Net is NOT a database while Access is a database and not even a good one
at that nor is it a multi-user database solution. I think you need to open
a book or read some articles and understand what ADO.Net is all about.


Maybe, you needed to start understanding development concepts and design
patterns.

MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

You trying to compare .Net and ADO.Net with Access and VBA, well what can be
said about it but ridiculous. :)
 
You trying to compare .Net and ADO.Net with Access and VBA, well what
can be said about it but ridiculous. :)
Click to expand...
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.
 
Jeroen Mostert said:
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.
Click to expand...

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 said:
I have used Access, and I have used VBA.
Click to expand...

So have I.
It's time has come and gone, mostly gone.
Click to expand...

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.
And no one in their right mind in making a serious desktop solution would
even consider it in today's environment IMHO.
Click to expand...

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.

That it's growing more obsolete by the day and shouldn't be used for new
projects is another matter. (Seriously, it shouldn't, as even Microsoft is
backing away from Jet and VBA like they have rabies, and it's dropping
support left and right -- good luck running it on a 64-bit system.)

That said, Access can still have its place for single-user scenarios.
Installing an SQL Server (Express) is often massive overkill. However, for
the client .NET is definitely a better choice than embedded VBA, because
migrating to a "real" solution should this become necessary will be much
easier. All this is mostly academic, though, because single-user desktop
database applications aren't that common in corporate environments.

For multi-user, you'll need a separate server anyway, so do it right from
the start and use a proper client/server architecture. There's every reason
not to use Access there.
 
Jeroen Mostert said:
So have I.


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.
Click to expand...

Migration is one thing? Support of old technology is another, something most
don't want to be bothered with it.
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.
Click to expand...

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.
 
Mr. Arnold wrote:
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.
Click to expand...
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.
Click to expand...
Yeah, but I think managers are actually grown somewhere, not raised.
 
Mr. Arnold wrote:



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.


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

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?
 
Mr. Arnold wrote:



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.


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

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?

What are the differnces between ADO and ADO.NET is more like it?

http://msdn2.microsoft.com/en-us/library/3y0bb1zd(VS.71).aspx

What's the differences between VB.Net and VB6 or VBA, which C#.Net surpasses
VB.Net in some areas, like pointers and anonymous delegates, with both
language solutions being managed code solutions using the .NET Framework?

http://www.ondotnet.com/pub/a/dotnet/excerpt/vbnetnut_appa/index.html

What is in the .NET Framework that VB6 nor VBA have an equivalent to it?

http://en.wikipedia.org/wiki/.NET_Framework
 
Back
Top