migrating Access app to ASP.NET?

[Jerome]

Hi there,

I've got an MS Access application with multiple tables, queries, forms
(and sub-forms!), reports ...

It would be neat if that application could be migrated to ASP.NET since
it wouldn't require the installation process anymore of each new user
who is supposed to work with it and the Office version hassle (97, 2000,
2004 etc) would be over too.

Now my question, is that really feasible? Access provides a GUI
experience that seems hard to simulate on a web interface.

Simple 'things' in Access seem to be difficult to emulate in the
browser: direct editing in forms; subforms (are subforms even
possible???); querying data from a second opened form; reports; ...

So when is it useful to make a web interface and when is it useful to
use ACCESS? Can an Access application be built using ASP.NET without
having to invest x times the amount of work in it?

Or would the solution be hybrid? Web for some users/tasks, Access for
others? But it seems weird to split the app in two?

Thanks everyone,

Jerome

 

[Sal Rosario]

Good question. I can only speak for myself. If an application will be
deployed to a specific set of users on a LAN, I'd go with the richness of an
Access front-end any day. But if an application will be accessed by a random
or undefined number of users, you need to build a web interface because you
cannot predit who will use your application.

For example, I rolled out a class registration database for a client with an
ASP front-end because it will be used by all its 600 and so employees to
enroll in classes. No way you are going to roll that out as an Access
front-end to all those people, right? So pretty much, it is a web "service".

--
Regards,

Sal Rosario
Microsoft Access Database Cosultant
www.salrosario.com


Hi there,

I've got an MS Access application with multiple tables, queries, forms
(and sub-forms!), reports ...

It would be neat if that application could be migrated to ASP.NET since
it wouldn't require the installation process anymore of each new user
who is supposed to work with it and the Office version hassle (97, 2000,
2004 etc) would be over too.

Now my question, is that really feasible? Access provides a GUI
experience that seems hard to simulate on a web interface.

Simple 'things' in Access seem to be difficult to emulate in the
browser: direct editing in forms; subforms (are subforms even
possible???); querying data from a second opened form; reports; ...

So when is it useful to make a web interface and when is it useful to
use ACCESS? Can an Access application be built using ASP.NET without
having to invest x times the amount of work in it?

Or would the solution be hybrid? Web for some users/tasks, Access for
others? But it seems weird to split the app in two?

Thanks everyone,

Jerome

 

[Arvin Meyer]

If you have very simple forms you may be able to duplicate their functions
in a web application. If the forms are complex, there is no way that you can
duplicate the richness of an Access form in a web application. You cannot
really do subforms in a web application, but there are similar things like a
form in an I-Frame. The biggest problem is expense. It will take at least 3
times as long and often as much as 5 or 6 times as long to build a web
application as to build an Access application.

For wide area networks, there isn't much choice unless you go with Terminal
Services, which can cost even more under certain circumstances.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Mark Andrews]

In my experience I only use pure Access applications for small niche
applications
that do not have many users. Everything else ends up going the SQl
Server/Web interface
route.

One hybrid approach is to migrate the reporting side of your Access
application to the web
and keep all data entry etc... using a full Access application. My company
makes a product to
help get Access reports to the web without requiring you to make many
changes in the reports
themselves. A good deal of applications have a few users that enter data
and a larger audience
that looks at the data using reports etc...

HTH,
Mark
RPT Software
http://www.rptsoftware.com