Converting an Access Application

  • Thread starter Thread starter Randy
  • Start date Start date
R

Randy

Hi all,

Not sure if this is feasible or not, but I'm gonna ask anyway.

My company has developed an application using MS Access 2k as a front end to
SQL Server 2000. As we grow, and add customers (who are also growing)
Access's limitations soon come to the fore front of most of our problems.

Is there a relatively easy way to convert from Access 2k to Vb .Net or even
VB 6 without basically re-writing the whole app?

I am thinking there isn't, but I thought I would ask those who are smarter
then I in this arena.

Thanks In Advance (even if it is bad news)

Randy
 
I have done it once and it was a total re-write. Took about 4-6 months.

The learning curve of .Net was steeper than I thought.
This is a project you should do as a way to learn .Net.
Don't do it under a time crunch.

Just my $.02.
 
I have learned some .Net, and I am pretty sure that the .Net conversion
would be horrendous. The only thing that sucks is that I would be doing it
on my own time. Well ... it would be cool to do it, and show it to my boss
.... but the time away from familky would kind of suck.

Thanks for yout $.02 - it echoes mine. Which is always nice!

Randy
 
The bad news is that you are going to have to face the fact that you *will*
have to rewrite it if you want to eliminate Access as it gets more and more
stretched - which from what you've said, means you will have to rewrite it.
The good news is that "re-writing" something in another language means just
that - re*writing* it. It doesn't mean re-researching application layout,
nor re-analyzing requirements, nor does it mean re-figuring-out algorithms -
you can take consolation in the fact that you don't have to go through the
same amount of work again to achieve the same-thing-only-different. Class
structure, control of flow design and possibly even tangible things such as
any ocxs / dlls there might be, can be kept.
You can optimize more aswell, by using SqlConnections which bypass OLEDB if
you're using SQL server like you say, the best approach is to use these
specific SQL server connections and use stored procedures for ALL data
access (it may sound hard at first but there's very few applications that
can't eliminate the need for dynamic SQL).
Given that you've already got this lot figured out, it would be a better
than average opportunity to learn .NET, if you don't already know it - or
more of it if you do. But use C# not VB.NET - VB.NET's just ...well,
*wrong*.
 
Joe Fallon said:
Very good points.
Up until the last one!

If that's the point you mean, it's the one that is most right! There is no
valid reason I can find for VB.Net to exist at all.
 
Back
Top