I don't have any personal experience with converting Access to .Net, but I
have heard of a commercial product called "Evolution" from
www.evolutionsoft.co.uk From reports, it seems to do a better job of
converting Access than MS' own VB6->Net converter (which is totally useless,
IMO).
As with any converter, YMMV as to how well it works. Some projects may
convert without a hiccup, others will result in a God-awful mess that you
could end up spending more time trying to fix than if you started over from
scratch. I would be particularly concerned about reports, macros, and
concurrent database access. If your Access app was designed as a multiuser
solution, you should be prepared to perform extensive stress testing to make
sure the converted app works the same way if its database operations do
translate to ADO.Net at all. Most conversions that I've come across tend to
just wrap the existing data access code with the .Net adodb component, or
simply invoke the legacy COM components directly. ADO.Net is strictly
disconnected, having no realtime access to the database, whereas in ADO or
its predecessors, you could work "live" with recordsets and tables. The
handling of concurrency can have subtle, yet dramatic consequences for an
application.
Frankly, my recommendation is that you take a serious look at the
application(s) you want to convert and determine if you wouldn't be better
off redesigning them from the ground-up for the .Net world. While you can
convert a good number of existing apps, there are many new capabilities and
techniques in .Net that can greatly simplify how things are done, or enable
you to do things you couldn't before. Simply translating old VB code won't
necessarily give you any of the real benefits of the new technology and, as
I said, you could wind up spending more time cleaning up. If you do explore
the converter route, approach it with few expectations for better than 40%
success, and realize you still may have to do considerable work to get what
you are hoping for out of it.
Alan
