S
Sean Kirkpatrick
I have a very ugly problem and I need some sincere guidance.
My legacy VB6 application depends heavily on DAO, especially as it
relates to custom properties on database objects. These custom
properties are, as I understand it, not avabilable with SQL Server,
which we need to migrate to in the not too distant future.
My boss, the owner of the company, requires that we provide for a
transition plan that minimizes (he really wants none) code changes to
the existing app (which is in use by over 8000 clients). It is also
required that we provide 100% backward compatibility with all of the
existing installed base, so we will never be able to abandon support for
Jet DBs. (Yes, never is a long time, but he still supports his DOS
product of 18 years ago!)
His desired solution is that we create a set of VB.Net interface classes
that presents a DAO like interface to the existing codebase. Then, we
implement two worker classes in VB.Net, one that uses DAO via Interop,
and then a few months from now, implement an ADO.Net worker class for
SQL Server that mimics the custom properties of Jet (this part is rather
straight forward, as we can do this using special tables.)
As I am exploring the topic, it seems that I'm going to have to make my
own collection classes (for the DAO recordset object, for example) and
pass those back to the app, essentially caching the DAO data. Yuck. I
can see memory usage and performance going right to hell, not to mention
the unintended consequences of failing to correctly implement some
aspect of DAO.
If I had my druthers I'd start over with a clean slate and rearchitect
this app to give it some reasonable object oriented structure and take
advantage of all that .Net has to offer - that just ain't gonna happen.
Are there any _sensible_ approaches to solving this problem?
Sean
My legacy VB6 application depends heavily on DAO, especially as it
relates to custom properties on database objects. These custom
properties are, as I understand it, not avabilable with SQL Server,
which we need to migrate to in the not too distant future.
My boss, the owner of the company, requires that we provide for a
transition plan that minimizes (he really wants none) code changes to
the existing app (which is in use by over 8000 clients). It is also
required that we provide 100% backward compatibility with all of the
existing installed base, so we will never be able to abandon support for
Jet DBs. (Yes, never is a long time, but he still supports his DOS
product of 18 years ago!)
His desired solution is that we create a set of VB.Net interface classes
that presents a DAO like interface to the existing codebase. Then, we
implement two worker classes in VB.Net, one that uses DAO via Interop,
and then a few months from now, implement an ADO.Net worker class for
SQL Server that mimics the custom properties of Jet (this part is rather
straight forward, as we can do this using special tables.)
As I am exploring the topic, it seems that I'm going to have to make my
own collection classes (for the DAO recordset object, for example) and
pass those back to the app, essentially caching the DAO data. Yuck. I
can see memory usage and performance going right to hell, not to mention
the unintended consequences of failing to correctly implement some
aspect of DAO.
If I had my druthers I'd start over with a clean slate and rearchitect
this app to give it some reasonable object oriented structure and take
advantage of all that .Net has to offer - that just ain't gonna happen.
Are there any _sensible_ approaches to solving this problem?
Sean