473,326 Members | 2,588 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Wrapping DAO, for better or worse

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
Nov 21 '05 #1
18 2017
Uggh haven't messed with DAO in a while. If you want to store custom
properties for your database objects, how about storing them in a table in
your database? You can wrap the SqlClient functionality in classes that
present the customer properties and should hide the changes from the
programmers/users pretty well. As for 100% backward compatibility, ugghh...
I would probably just provide an upgrade tool to get users of the old
product into the new century... After all, MSDE is free...

"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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

Nov 21 '05 #2
Sean,
| 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.
You would be implementing simply Proxy classes, in my experience simply
Proxy classes do not have adverse effects on memory usage or performance.
Seeing as you want to work with either DAO or ADO.NET, I would recommend an
Adapter pattern. Where you have a base class that defines the interface for
the Adapter, then DAO & ADO.NET concrete classes that define the
implementation of the interface...

| 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.
You can still do this & support both DAO & SQL Server. You could define a
Domain Model & then define 2 specific Data Mappers: one Data Mapper does
SqlClient and one does DAO. (I define a base classes for my Data Mappers to
minimize coupling).

http://www.martinfowler.com/eaaCatalog/domainModel.html

http://www.martinfowler.com/eaaCatalog/dataMapper.html

If you define the base class for your Data Mappers correctly, you should be
able to introduce support for Oracle, AS/400 or any other datasource (such
as an Xml File).

In addition to/instead of the Domain Model & Data Mapper patterns you could
also use the Table Module & Table Data Gateway patterns.

http://www.martinfowler.com/eaaCatalog/tableModule.html

http://www.martinfowler.com/eaaCatal...taGateway.html
| 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.
SQL Server 2000 fully support custom properties on database objects. Lookup
"Extended Properties" in the BOL.

http://www.microsoft.com/sql/techinf...properties.asp

http://msdn.microsoft.com/library/de...l/sql02a10.asp

Hope this helps
Jay
"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
|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
Nov 21 '05 #3
On Tue, 19 Jul 2005 10:49:36 -0700, Sean Kirkpatrick <na**********@community.nospam> wrote:

¤ 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?

I see several problems with attempting to impose a DAO interface, the primary of which would be that
the architecture is sufficiently different to cause a major headache when integrating with ADO.NET
database objects or SQL Server.

While you may be able to work with an underlying DAO Recordset, it doesn't translate directly to
ADO.NET. That will be an interop stumbling block. With respect to developing a custom interface that
mimics DAO, once again, the way in which DAO was designed to function is different than ADO.NET. Not
even Microsoft would develop a native DAO interface assembly for .NET.

You also have to consider that DAO was designed to operate through a persistently connected
environment, typically with a file based database, while ADO.NET's connections are generally
available only for the duration of the database update or query. This could be very different than
your current architecture if you're using an Access database.

Personally, since you're not only migrating to another development product but also from a file
based to server database, I would abandon the notion of trying to mimic the DAO interface in .NET.
Paul
~~~~
Microsoft MVP (Visual Basic)
Nov 21 '05 #4
Why don't you skip the bit involving creating a DAO wrapper, and just go
straight to the bit that involves "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.)" .. ?

This sounds like how I'd do it...
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

Nov 21 '05 #5
Paul Clement wrote:

Personally, since you're not only migrating to another development product but also from a file
based to server database, I would abandon the notion of trying to mimic the DAO interface in .NET.


You're preaching to the choir, but this ignores the much more
fundamental problem: I do not have a choice to abandon DAO - the owner
of the company has mandated that this be done. I am directed to write
some sort of interface that looks like DAO such that under the covers, I
can substitute a different class that interacts with any old arbitrary
DB engine. This means that I am going to have to implement my own
Recordsets, Fields, Properties, and etc. so that the existing code works
without (much) change, and provide translations from the native DB
notion of these entities.

It is not pretty.

Silly? Yep. Other choices? Nope.

Sean
Nov 21 '05 #6
That was my initial approach, but it doesn't solve the backwards
compatibility problem: i.e., I must continue to support those 8000+
clients out there who are using Jet DBs (some of whom have written their
own custom addins to my product that likewise depend on Jet custom
properties.) Also, my boss does not want to migrate right now to to
MSDE/SQL Express, so my alternatives are severely constrained.

Sean

Bonj wrote:
Why don't you skip the bit involving creating a DAO wrapper, and just go
straight to the bit that involves "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.)" .. ?

This sounds like how I'd do it...

Nov 21 '05 #7
Sean,
You can use DAO via COM interop, you don't need to write any wrappers per
se. The COM interop writes all the wrappers you need...

When you are ready to implement the SQL side of things, you could (could)
simple define your own classes that implement the interfaces from DAO.

I however would take a different approach. I would decouple the current app
from DAO, encapsulating all the DAO code in my own data objects. Then when
you are ready for SQL, you would create a new set of data objects that
talked SQL Client instead of DAO.

Of course depending on how tightly the current app is coupled to DAO
creating data objects might not be a viable option.

Hope this helps
Jay

"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:uv**************@TK2MSFTNGP12.phx.gbl...
| Paul Clement wrote:
|
|
| > Personally, since you're not only migrating to another development
product but also from a file
| > based to server database, I would abandon the notion of trying to mimic
the DAO interface in .NET.
| >
|
| You're preaching to the choir, but this ignores the much more
| fundamental problem: I do not have a choice to abandon DAO - the owner
| of the company has mandated that this be done. I am directed to write
| some sort of interface that looks like DAO such that under the covers, I
| can substitute a different class that interacts with any old arbitrary
| DB engine. This means that I am going to have to implement my own
| Recordsets, Fields, Properties, and etc. so that the existing code works
| without (much) change, and provide translations from the native DB
| notion of these entities.
|
| It is not pretty.
|
| Silly? Yep. Other choices? Nope.
|
| Sean
Nov 21 '05 #8
On Wed, 20 Jul 2005 10:39:07 -0700, Sean Kirkpatrick <na**********@community.nospam> wrote:

¤ Paul Clement wrote:
¤
¤
¤ > Personally, since you're not only migrating to another development product but also from a file
¤ > based to server database, I would abandon the notion of trying to mimic the DAO interface in .NET.
¤ >
¤
¤ You're preaching to the choir, but this ignores the much more
¤ fundamental problem: I do not have a choice to abandon DAO - the owner
¤ of the company has mandated that this be done. I am directed to write
¤ some sort of interface that looks like DAO such that under the covers, I
¤ can substitute a different class that interacts with any old arbitrary
¤ DB engine. This means that I am going to have to implement my own
¤ Recordsets, Fields, Properties, and etc. so that the existing code works
¤ without (much) change, and provide translations from the native DB
¤ notion of these entities.
¤
¤ It is not pretty.
¤
¤ Silly? Yep. Other choices? Nope.
¤
¤ Sean

Not that management would understand (or even care about) the ramifications of attempting to do what
they are requesting, but I just wanted you to understand what you're in for.

It's one thing to abstract the data access method from your application so that is can be easily
changed once technology changes, but it's quite another to attempt to retrofit an old architecture
into a new one.
Paul
~~~~
Microsoft MVP (Visual Basic)
Nov 21 '05 #9
Hi Jay.

Any and all of this discussion helps, if only to clarify my thinking.

First of all, thanks for the reference to Fowler's book - I just went
out and picked up a copy of it and am about to dig in.

I think we're on the same page here: what I'm calling wrappers you're
calling data objects.

Let me run this past you.

It seems like I should write my own abstract class heirarchy beginning
with a CDatabase object that has an OpenRecordset call that returns a
CRecordset object. Then, I'll write write a subclass that implements
these in terms of DAO calls, and later a SQL Server subclass. Then, with
proper redeclaration of variables in my app, the essential call
structure remains the same.

This means that I have to provide my own Recordset class collection that
maps DAO records sets to my own, as well as to ADO.Net recordsets. I
don't have to (and am not yet planning on) implementing the ADO.Net map.

Another related question: It is highly likely that I will pass off the
ADO.Net mapper off to another fellow in the shop here. I want to make
sure that he implements the same interface that I define in its
entireity. This suggests that I should define a suite of Interface
classes that he must implement. However, I've discovered that there's a
few wrinkles with this in that I really want to make typesafe collection
classes for Fields, Properties, and the like.

I think an alternative is to define a set of abstract base classes with
MustOverride methods.

Are there other things that I need to consider?

Thanks for your help and insight. This has not been an easy or fun
project for me to work on - if you saw the extant code base you'd know why.

Sean
Jay B. Harlow [MVP - Outlook] wrote:
Sean,
You can use DAO via COM interop, you don't need to write any wrappers per
se. The COM interop writes all the wrappers you need...

When you are ready to implement the SQL side of things, you could (could)
simple define your own classes that implement the interfaces from DAO.

I however would take a different approach. I would decouple the current app
from DAO, encapsulating all the DAO code in my own data objects. Then when
you are ready for SQL, you would create a new set of data objects that
talked SQL Client instead of DAO.

Of course depending on how tightly the current app is coupled to DAO
creating data objects might not be a viable option.

Hope this helps
Jay

Nov 21 '05 #10
At some point you're going to have to completely (?) re-engineer the
product. For now, however, Jay's solution is probably the best so far.
Abstract the database objects. That way your application won't know, or
care, where the data is coming from. I would implement my own interfaces,
based on my application's needs; not trying to duplicate the DAO COM - or
other - interfaces.

For instance, you might have a method that sets an extended property value
for an object. Let's call it SetExtendedProp(ObjectName, PropertyName,
Value) [very simplified example]. You can call SetExtendedProp() on a DAO
datasource and it will set the extended properties appropriately via DAO.
We can replace/override this method later with an ADO.NET version. The app
wouldn't care what method we're using to store or manipulate the data --
whether it's DAO, ADO.NET, XML or even Flat Files. As long as the interface
is the same, the inner plumbing doesn't matter.

I think that's what Jay was talking about with de-coupling the app from the
data manipulation routines. I would start by looking at the high-level data
manipulation functions as opposed to the low-level plumbing. Once you have
the interfaces set up for that, it's a simple (theoretically) matter to
change out the inner plumbing.

"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:ek**************@TK2MSFTNGP14.phx.gbl...
That was my initial approach, but it doesn't solve the backwards
compatibility problem: i.e., I must continue to support those 8000+
clients out there who are using Jet DBs (some of whom have written their
own custom addins to my product that likewise depend on Jet custom
properties.) Also, my boss does not want to migrate right now to to
MSDE/SQL Express, so my alternatives are severely constrained.

Sean

Bonj wrote:
Why don't you skip the bit involving creating a DAO wrapper, and just go
straight to the bit that involves "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.)" .. ?

This sounds like how I'd do it...

Nov 21 '05 #11
Sean,
Database & Recordset objects would be one route. Data Mappers would be
another. Although the Data Mappers could use an abstraction level over the
actual database itself. Have you looked at the Data Access Application Block
from the Enterprise Library?

http://msdn.microsoft.com/library/de.../html/daab.asp

It might be a good starting point.

I would probably make them abstract base classes, my program itself would
only use the abstract base classes, I would read which concrete class (DAO
or SQLCLient based) to create based on a setting my app.config file.

Hope this helps
Jay
"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:e2**************@TK2MSFTNGP09.phx.gbl...
| Hi Jay.
|
| Any and all of this discussion helps, if only to clarify my thinking.
|
| First of all, thanks for the reference to Fowler's book - I just went
| out and picked up a copy of it and am about to dig in.
|
| I think we're on the same page here: what I'm calling wrappers you're
| calling data objects.
|
| Let me run this past you.
|
| It seems like I should write my own abstract class heirarchy beginning
| with a CDatabase object that has an OpenRecordset call that returns a
| CRecordset object. Then, I'll write write a subclass that implements
| these in terms of DAO calls, and later a SQL Server subclass. Then, with
| proper redeclaration of variables in my app, the essential call
| structure remains the same.
|
| This means that I have to provide my own Recordset class collection that
| maps DAO records sets to my own, as well as to ADO.Net recordsets. I
| don't have to (and am not yet planning on) implementing the ADO.Net map.
|
| Another related question: It is highly likely that I will pass off the
| ADO.Net mapper off to another fellow in the shop here. I want to make
| sure that he implements the same interface that I define in its
| entireity. This suggests that I should define a suite of Interface
| classes that he must implement. However, I've discovered that there's a
| few wrinkles with this in that I really want to make typesafe collection
| classes for Fields, Properties, and the like.
|
| I think an alternative is to define a set of abstract base classes with
| MustOverride methods.
|
| Are there other things that I need to consider?
|
| Thanks for your help and insight. This has not been an easy or fun
| project for me to work on - if you saw the extant code base you'd know
why.
|
| Sean
|
|
| Jay B. Harlow [MVP - Outlook] wrote:
| > Sean,
| > You can use DAO via COM interop, you don't need to write any wrappers
per
| > se. The COM interop writes all the wrappers you need...
| >
| > When you are ready to implement the SQL side of things, you could
(could)
| > simple define your own classes that implement the interfaces from DAO.
| >
| > I however would take a different approach. I would decouple the current
app
| > from DAO, encapsulating all the DAO code in my own data objects. Then
when
| > you are ready for SQL, you would create a new set of data objects that
| > talked SQL Client instead of DAO.
| >
| > Of course depending on how tightly the current app is coupled to DAO
| > creating data objects might not be a viable option.
| >
| > Hope this helps
| > Jay
| >
Nov 21 '05 #12

Michael C# wrote:
At some point you're going to have to completely (?) re-engineer the
product. For now, however, Jay's solution is probably the best so far.
Abstract the database objects. That way your application won't know, or
care, where the data is coming from. I would implement my own interfaces,
based on my application's needs; not trying to duplicate the DAO COM - or
other - interfaces.

Right, this makes sense and is my current "best thought" (thanks to you
guys.) Insofar as defining my own interfaces, I really can't do that,
since the mandate is to "look and behave like DAO". This means that my
interface is "specified" since DAO tells me what the i-face has to look
like.

I've started defining an AbstractDB class with methods that map to those
DAO methods that I use (thankfully not all of them) such OpenRecordset
and so on. Then I'll implement concrete classes that do the work, such
as JetDB and SQLSvrDB. My app code can then look and behave the way that
it currently does. I think this may solve my problem.
Sean
Nov 21 '05 #13
Sean,
You should be able to have "YourConnection" implement DAO.Connection, then
every place you are using a DAO.Connection, you use a YourConnection
instead. However you would still use a DAO.Connection variable.

Something like:

Public Class YourConnection
Implements dao.Connection

Public Sub Cancel() Implements dao.Connection.Cancel

End Sub

Public Sub Close() Implements dao.Connection.Close

End Sub

....
End Class
Of course you would need to limit where you use "New DAO.Connection",
instead calling a function in a Module that created either a real
DAO.Connection or a YourConnection object. Same with the other DAO object
types.

Dim connection As DAO.Connection
connection = CreateConnection()

Public Function CreateConnection() As DAO.Connection
If usingSQL Then
Return New YourConnection
Else
Return New DAO.Connection
End If

However I would not define a YourConnection unless my boss was really,
*really*, animate about using "DAO" in my code. I would favor decoupling my
code from DAO & Recordset by using one of the Fowler patterns...

Of course you need to remember that .NET does not officially support DAO.

http://msdn.microsoft.com/library/de...tovbdotnet.asp

Of course COM Interop is supported & DAO is a COM object...

Hope this helps
Jay

"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:Oe**************@TK2MSFTNGP14.phx.gbl...
|
| Michael C# wrote:
| > At some point you're going to have to completely (?) re-engineer the
| > product. For now, however, Jay's solution is probably the best so far.
| > Abstract the database objects. That way your application won't know, or
| > care, where the data is coming from. I would implement my own
interfaces,
| > based on my application's needs; not trying to duplicate the DAO COM -
or
| > other - interfaces.
| >
| Right, this makes sense and is my current "best thought" (thanks to you
| guys.) Insofar as defining my own interfaces, I really can't do that,
| since the mandate is to "look and behave like DAO". This means that my
| interface is "specified" since DAO tells me what the i-face has to look
| like.
|
| I've started defining an AbstractDB class with methods that map to those
| DAO methods that I use (thankfully not all of them) such OpenRecordset
| and so on. Then I'll implement concrete classes that do the work, such
| as JetDB and SQLSvrDB. My app code can then look and behave the way that
| it currently does. I think this may solve my problem.
|
|
| Sean
Nov 21 '05 #14
As some of you may recall, I have marching orders to implement wrapper
classes in VB.Net to implement a DAO-like interface so that we can
evolve our legacy VB6 app from DAO to SQL Server, and eventually the app
itself to .Net. I truly wish that I could completely abandon the use of
DAO, but that is just not an option.

I have a nearly functional version of these wrappers working and for the
most part, things seem to work very well. The approach I've taken thanks
to your input is to define a set of abstract base classes that map 1 to
1 with the DAO interface.

Project Wrappers
ACDatabase
ACTableDefs
Inherits CollectionBase
ACTableDef
ACIndexes
Inherits CollectionBase
ACIndex
ACProperties
Inherits CollectionBase
ACProperty

and so on. The collection classes, Tabledefs, Indexes, Properties, and
such, all inherit from Collection Base which gives me nifty capabilities
such as Count, Item, and so on.

Then, I've got two sets of concrete classes each in their own namespaces:

DAO_DB_NS and SQL_SERVER_DB_NS, each implementing concrete classes for
their own functionality. Thankfully, I only have to implement the DAO
side of things, as they are largely passthrough to the DAO 3.6 lib.

CDatabase
CTabledefs
Inherits ACTableDefs
CTabledef
CIndexes
Inherits ACIndexes
CProperties
Inherits ACProperties

and so on.

I'm able to do just about anything that I need to with this as it's
currently implemented, and I must say that I'm surprised that it works
as well as it does.

There is one wrinkle that I can't seem to figure out, however, and I
wonder if anyone can help.

On a TableDef object are several collections, Indexes, Fields,
Properties. I know that my DB has each of them as I can write a simple
prog in VB6 to walk the Indexes collection.

for each oTD as CTabledef in CTabledefs
for each oIdx as CIndex in oTD.Indexes
do something with each index
next
next

This works like a charm. HOWEVER, if I try to access the count property
for ANY of the indexes, it always returns 0.

if oTD.Indexes.Count > 0 then
do something else
end if

If I write the same essential code in VB.Net, it works correctly, that
is, the count property always returns the correct answer.

I've wondered if somehow this might be related to the fact that I
specify that my abstract classes inherit from CollectionBase and somehow
the internal list is not being initialized (each time I refer to a
Csomething, I rebuild the inherited List from the actual DAO object),
but if that were the case, it shouldn't work correctly when I test in in
..Net.

I'm really puzzled by this behavior. Does anyone have a clue for me
'cause I'm clueless?

One way that I've found to get around the problem is to write an
overloaded Count property that returns actual DAO count property for the
object in question. But this shows up in VB6 as Count_2. I suppose
that if I need to, I can change the legacy code to use Count_2 - I'm
already doing that for the Item property.

Thanks!

Sean

Nov 21 '05 #15
Hi

From your description,
if oTD.Indexes.Count > 0 then
do something else
end if
The code above will work in vb.net, but when you expose it to vb6 as COM,
the count will not work.
Because .NET class works somewhat different with unmanaged code.
Have you tried to get the Indexes first and then call its Count.
e.g.
dim o as CIndexes
set CIndexes = oTD.Indexes
? o.Count

Did that works?

Since this is wrap for DAO, so in VB6 why you did not use DAO directly but
use the wrap class instead.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 21 '05 #16
It turns out that the problem was being caused by having .Net Framework
2.0 beta 2 loaded on the same machine that I am testing my wrappers on.
On my laptop at home, the code works just fine but on my machine at
work, it does not. That lead me to exploring the differences between the
two machines and lo and behold, the 2.0 Beta 2 framework was installed
at work. Removing the beta installation and the code works as designed.

Moral of the story, be careful, very careful, about loading beta
versions of s/w on development machines.

Sean

Peter Huang [MSFT] wrote:
Hi

From your description,
if oTD.Indexes.Count > 0 then
do something else
end if
The code above will work in vb.net, but when you expose it to vb6 as COM,
the count will not work.
Because .NET class works somewhat different with unmanaged code.
Have you tried to get the Indexes first and then call its Count.
e.g.
dim o as CIndexes
set CIndexes = oTD.Indexes
? o.Count

Did that works?

Since this is wrap for DAO, so in VB6 why you did not use DAO directly but
use the wrap class instead.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 21 '05 #17
Hi

Thanks for your quickly reply!
Commonly we can use the <supportedRuntime> Element in the app.config to
specified the runtime you are going to use.
<supportedRuntime> Element
http://msdn.microsoft.com/library/de...us/cpgenref/ht
ml/gnconSupportedRuntimeElement.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 21 '05 #18
Sean,

Good information to know, I typically avoid anything Beta on primary
development PCs. I have another MS test PC that I dump/migrate production
code over to just for test and see purposes.

I too still like DAO over OLEDB and the performance testing I've done with
DAO on MS Access databases vs. OLEDB on MS Access databases has shown a
considerable performance gain using DAO.

Rob.

"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:ON**************@TK2MSFTNGP10.phx.gbl...
It turns out that the problem was being caused by having .Net Framework
2.0 beta 2 loaded on the same machine that I am testing my wrappers on. On
my laptop at home, the code works just fine but on my machine at work, it
does not. That lead me to exploring the differences between the two
machines and lo and behold, the 2.0 Beta 2 framework was installed at
work. Removing the beta installation and the code works as designed.

Moral of the story, be careful, very careful, about loading beta versions
of s/w on development machines.

Sean

Peter Huang [MSFT] wrote:
Hi

From your description, if oTD.Indexes.Count > 0 then
do something else
end if
The code above will work in vb.net, but when you expose it to vb6 as COM,
the count will not work.
Because .NET class works somewhat different with unmanaged code.
Have you tried to get the Indexes first and then call its Count.
e.g. dim o as CIndexes
set CIndexes = oTD.Indexes
? o.Count

Did that works?

Since this is wrap for DAO, so in VB6 why you did not use DAO directly
but use the wrap class instead.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.

Nov 21 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
by: Roy Smith | last post by:
I've got a C library with about 50 calls in it that I want to wrap in Python. I know I could use some tool like SWIG, but that will give me a too-literal translation; I want to make some...
2
by: Alex Dribin | last post by:
Hi, Are there ready solutions for auto-wrapping lines in ostream? I am using ostream for output and want this output to be wrapped at some position. Of course I can monitor stream pointer...
11
by: yawnmoth | last post by:
word wrapping normally treats some spaces as line feeds, if there hasn't been a line feed for quite a while. so while a string with eighty consecutive a's might not word wrap, a space placed...
12
by: sneill | last post by:
Hello, I have the following HTML / CSS that draws 2 rows. Each row has 3 cells. I want the cells within each row to span a single line. Each cell is 100px wide, and the row containing them is...
14
by: Sean C. | last post by:
Helpful folks, Most of my previous experience with DB2 was on s390 mainframe systems and the optimizer on this platform always seemed very predictable and consistent. Since moving to a WinNT/UDB...
10
by: Douglas G | last post by:
I've tried various ideas on this problem, but I don't see word wrapping. Can you point out what is wrong? It's a K&R exercise, and I'm still new to programming. Other pointers would be helpful...
85
by: masood.iqbal | last post by:
I know that this topic may inflame the "C language Taleban", but is there any prospect of some of the neat features of C++ getting incorporated in C? No I am not talking out the OO stuff. I am...
6
by: Markus Ernst | last post by:
Hi Searching for a possibility to display some text with preserved white space and line breaks, but with long lines being wrapped, I found this CSS declaration, which I found helpful: pre {...
9
by: trondhuso | last post by:
Hi, I have a solution that - at time of writing - has to use tables to render a list of database-results. My challenge though is that we have used iframes and such to render the different lists...
43
by: Pawel_Iks | last post by:
I've read somewhere that c++ is something more than better c ... then I talk with my friend and he claimed that c++ is nothing more than better c ... I tried to explain him that he was wrong but I...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.