convert access to dot net

[homer]

I am looking for ways of converting MS Access application to dot net.
I found several websites saying they can do the job. I’d like to here any
recommendation from the group.
Here are the ones I found, and my concerns based on my preliminary assessment.

Greenwich Financial Modeling Inc. (http://www.gfminc.com/)
They had been on Access journals years back, but their latest news on the
site was dated 2001, and I could not get a email reply from them. Are they
still in business? Their product only converts to VB6.

MicroTools(http://www.microtools.us/default.htm) Their product is cheap, and
their site looks less sophisticated. My big question for them is can they do
a decent job.

Diamond Edge(http://www.diamondedge.com). Their products are more on
converting to Java platform side.

Thank you in advance for your help!

 

[Douglas J. Steele]

The general consensus for all such products seems to be that they do an
incomplete job at best.

There are simply too many differences between the controls available on
Access forms and those available on forms in .Net or other platforms.

 

[Norman Yuan]

IMO, unless your Access app is extremely simple, it is next to impossible to
convert Access app to a .NET app (Window app or Web app? They are so
different) without manually fixing. Even converting to VB app is far from
desirable.

For example, the difference between VB6 win app and .NET win app is
certainly smaller than the difference between Access app and .NET app. MS
made VB migration wizard to help VB6 programmer to convert their VB app to
..NET app. You'd expect it works well. because MS are so eager to lure more
VB programmers to .NET. The fact is, that tool hardly does an acceptable
conversion.

If the Access app is a serious business app, I'd either leave it alone until
its natural death, or re-write in .NET. Converting by third party tool may
only be considered as temporary/emergent solution in this case

 

[Albert D. Kallal]

As others have mentioned the conversion tools don't do a "instant" job. They
will move code, and do a good deal of form layout for you.

However, if you got a small application (say 150 forms), then the time save
by using one of these tools could certainly justify the cost. However, make
no mistake about this..you will have to be a experienced .net coder. You
will have to spend a few months. (remember, ms-access has/had a STEEPER
learning curve then VB6..).

Skill level required for a successful conversion:

The skill level of the developer will make or break the project regardless
of the "conversion" issues.

I am a better hockey coach when Wayne Gretzky is on the team.

Hence the #1 consideration is at what level the developer is at. There are
certainly more levels then just "trained" or "not trained". Generally there
are a "lot" of skill levels, but the following breakdown is sufficient. **

Stage 1 Innocent (never heard of the product)

Stage 2 Aware (Has read an article about X)

Stage 3 Apprentice (has attended a three-day seminar)

Stage 4 Practitioner (ready to use X on a real project)

Stage 5 Journeyman (uses X naturally and automatically in his job)

Stage 6 Master (has internalized X, knows when to break the rules)

Stage 7 Expert (writes books, gives lectures, looks for ways to extend x)


One should NEVER attempt a project with a team consisting with Stage 3 or
lower people. This is a sure fire formula for failure. The team can consist
of stage 4's, but they should have at least access to Stage 5, or 6. This
requirement is needed both in .net and Ms-Access.

the other issue here is why do you need to convert to .net? We had at least
3 new versions of ms-access (since VB6 stopped being improved). Further, ms
is hard at work on the next great version of ms-access.

And, remember, as new technology comes out, then MS tends to add these new
things to ms-access.

When officce 97 came out, the big "new" deal was now that you can write, and
create class objects. So, since other tools at that time were getting the
abiliry to make class objects, then MS added this feature to ms-access. YOu
can read about making class objects in ms-access here:

http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html

Furhter, when ado came out for accessing database servers, then again, this
feature was added to ms-access. And, now that XML is a big deal, we got XML
supprot in ms-access for access2002, and the xml supprot is even better in
a2003.

And, also, Microsoft has now released the SOAP tool kit for ms-access. This
means that now ms-access can consume, and use .net web services. So, while
you can't write web services in ms-access, you can consume any .net web
services via the SOAP add in anyway. So, if you need to write something new
in .net...you can do so..and ms-access can consume that service.

So, it seems quite clear to me, that as each new technology that comes along
that MS is promoting, they spent the money on ms-access and added these
"new" technological features.

So, this kind of begs the question......why do you need to change to .net?

 

[homer]

Thank you very much for all three of you.
To use Albert's skill level, we currently have two programmers. I am at
stage 4 on both dot net and Access, and the other one is 5 on Access, but 2
on dot net.

We are a 30 million/annual revenue manufacturing company. Near 50% of the
applications are Access 97 front end with SQL Server 2000 backend. We just
converted from Sybase to SQL Server months ago.

The number one reason that we want to upgrade is the poor performance/slow
response time of current access apps. I know moving away from DAO into ADO,
from passthrough to Stored Procs, from linked tables to DSN less calls will
help.

But my new boss wants to find a quick way to convert...

 

[Rick Brandt]

Thank you very much for all three of you.
To use Albert's skill level, we currently have two programmers. I am at
stage 4 on both dot net and Access, and the other one is 5 on Access, but 2
on dot net.

We are a 30 million/annual revenue manufacturing company. Near 50% of the
applications are Access 97 front end with SQL Server 2000 backend. We just
converted from Sybase to SQL Server months ago.

The number one reason that we want to upgrade is the poor performance/slow
response time of current access apps. I know moving away from DAO into ADO,
from passthrough to Stored Procs, from linked tables to DSN less calls will
help.

But my new boss wants to find a quick way to convert...

There is absolutely nothing about a dot-net app that will be inherently faster
than what you are using. What you need to do is find the areas in your Access
app that are set up poorly and fix them. Access over SQL Server is perfectly
capable of being every bit as fast as any other solution providing that the same
data retrieval methods are used.

On top of that, switching to more pass-throughs and stored procs is not the
panacea you seem to think it is. It is actually fairly rare for such a change
to yield much improvement. In cases where those can increase performance it is
a trivial thing to do. Choosing to re-write in a new technology instead of
making some fairly simple changes seems a drastic thing to do.

Don't get me wrong. If you want to move to dot-net for (whatever) reasons then
more power to you, but if you have to "sell" this to management and are doing so
on the premise that it will improve performance I wouldn't want to bet my career
on the outcome. It would be far more prudent to find some new projects to do in
dot-net first and see if you (and the bosses) are impressed with the results.
Or possibly pick some existing area and port it over to see if *tangible*
benefits can be found.