Switch To .NET As RAD Tool: Anybody Done It?

[(PeteCresswell)]

About every 10 months or so I get this wild idea that I should
develop a skeleton .NET application and start doing RAD using
..NET instead of MS Access.

Even tried climbing the .NET learning curve once or twice.

My rational:
--------------------------------------------------
1) IT looks more kindly on .NET

2) If man hours could be kept to a factor of two or
three, probably nobody would notice.

3) There are some *really* impressive third-party
controls available for .NET/SQL Server.
--------------------------------------------------


Has anybody actually ditched Access in favor of .NET for rapid
turnaround/rapid response projects?

Holes in my rationale?

 

[David W. Fenton]

About every 10 months or so I get this wild idea that I should
develop a skeleton .NET application and start doing RAD using
.NET instead of MS Access.

You mean switch to .NET from a RAD tool (which is what Access is)?

I think it's a matter of insanity to even consider the move. How
could .NET be better for any app for which Access is appropriate? It
can't!

 

[John Mishefske]

About every 10 months or so I get this wild idea that I should
develop a skeleton .NET application and start doing RAD using
.NET instead of MS Access.

FWIW, I've wrestled with how to move to the .NET world without giving up
the RAD abilities of Access. I use .NET Class Libraries to extend my
A2007 applications and link these two 'worlds' together.

Access provides that great event-rich fat client UI and it is relatively
easy to hook it up to a .NET class library to provide (.NET) server DBMS
hook-ups or perhaps even MVC-type application partition. But, in its
present form, Access will always tend to be a fat-client in an
increasingly thin-client world.

Great for small shop clients, not so much for larger and/or distributed
clients.

An experienced Access developer can benefit from its (low-overhead) use
as a RAD or prototype tool for demo or proof-of-concept use providing
UI, db schema and reporting facilities in tight time frame or cost
scenarios.

And its use as an ad-hoc front-end tool to a server DBMS is hard to beat.

IMO, Access still provides the best tool for fulfilling small shop needs
because of its wide-ranging abilities (UI, reporting, extensibility,
DBMS support, multi-user, etc.). But, obviously, loses appeal where
scalability and extendability are important.

I've split my focus now between traditional Access development and the
newer ASP.NET technology to provide a wider range of services to my
clients.

Pete - just my experience and I'm sure this isn't anything new to you;
I'm struggling to find the right transition path too.

--
John Mishefske, Microsoft MVP 2007 - 2009
UtterAccess Editor
Tigeronomy Software
web: http://www.tigeronomy.com
email: sales ~at~ tigeronomy.com

 

[James A. Fortune]

FWIW, I've wrestled with how to move to the .NET world without giving up
the RAD abilities of Access. I use .NET Class Libraries to extend my
A2007 applications and link these two 'worlds' together.

Access provides that great event-rich fat client UI and it is relatively
easy to hook it up to a .NET class library to provide (.NET) server DBMS
hook-ups or perhaps even MVC-type application partition. But, in its
present form, Access will always tend to be a fat-client in an
increasingly thin-client world.

Great for small shop clients, not so much for larger and/or distributed
clients.

An experienced Access developer can benefit from its (low-overhead) use
as a RAD or prototype tool for demo or proof-of-concept use providing
UI, db schema and reporting facilities in tight time frame or cost
scenarios.

And its use as an ad-hoc front-end tool to a server DBMS is hard to beat.

IMO, Access still provides the best tool for fulfilling small shop needs
because of its wide-ranging abilities (UI, reporting, extensibility,
DBMS support, multi-user, etc.). But, obviously, loses appeal where
scalability and extendability are important.

I've split my focus now between traditional Access development and the
newer ASP.NET technology to provide a wider range of services to my
clients.

Pete - just my experience and I'm sure this isn't anything new to you;
I'm struggling to find the right transition path too.

That topic is discussed in the following thread:

http://groups.google.com/group/comp.databases.ms-access/browse_frm/thread/6e86b7ff8d3b7894

Besides other activities I'm doing to learn C#, I'm planning on taking a
C# and .NET Framework course from a database person to help get ready
for what I believe to be an essential part of customizing Access in the
future. I'm looking for that transition path too, but I believe
strongly that I need to find it, or something very close to it.

Thanks again John for the links.

James A. Fortune
(e-mail address removed)