Access / DAO - What's the Future

  • Thread starter Thread starter TrevorS
  • Start date Start date
T

TrevorS

We are using Access as the "repository" for a C++ MFC application. It's
single user.
The schema is complex (100 tables) and can be a few hundred MBytes in
size.

We are starting to reach the limits: occassionl "Query too Complex" and
"Max Lock Files Exceeded". Although some of these we have tackled and
got around through better design.

We recently moved to Visual Studio 2005 and of course no longer have
the benifit of DAO wizards for creating RecordSets and refreshing them
when the schema changes. This too we have got around for now - just
using old classes as a model and creating them by hand.

We are about to start the next phase of our product and it will stress
the database even more.

The questions:

o Would you recommend that we change to SQL Server Express?
o What are our migration options? Do we have to convert everything to
ADO right away? I assume we can't use DAO with SQL Server. If we could
we migrate slowly - using ADO (or ODBC) for new classes.
o Or should we use ODBC?

Thanks
TrevorS.
 
Hi Trevor,

TrevorS said:
We are using Access as the "repository" for a C++ MFC application. It's
single user.
The schema is complex (100 tables) and can be a few hundred MBytes in
size.

We are starting to reach the limits: occassionl "Query too Complex" and
"Max Lock Files Exceeded". Although some of these we have tackled and
got around through better design.

We recently moved to Visual Studio 2005 and of course no longer have
the benifit of DAO wizards for creating RecordSets and refreshing them
when the schema changes. This too we have got around for now - just
using old classes as a model and creating them by hand.

We are about to start the next phase of our product and it will stress
the database even more.

The questions:

o Would you recommend that we change to SQL Server Express?
Click to expand...

Most definitely. Perhaps you might consider Sql Server Everywhere, too
(single user, no install required - just copy&paste assemblies).
o What are our migration options? Do we have to convert everything to
ADO right away? I assume we can't use DAO with SQL Server. If we could
we migrate slowly - using ADO (or ODBC) for new classes.
Click to expand...

Not sure about migration. However if you want to take advantage of .net then
you should go with ado.net and its native providers or even better, use an
ORM (i.e. LLBLGenPro - does many things for you, like wizards, but better)
if it fits your needs.
o Or should we use ODBC?
Click to expand...

ODBC via ado.net is still an option but .. .see above.
 
Miha said:
Hi Trevor,



Most definitely. Perhaps you might consider Sql Server Everywhere, too
(single user, no install required - just copy&paste assemblies).


Not sure about migration. However if you want to take advantage of .net then
you should go with ado.net and its native providers or even better, use an
ORM (i.e. LLBLGenPro - does many things for you, like wizards, but better)
if it fits your needs.


ODBC via ado.net is still an option but .. .see above.
Click to expand...

Thanks Miha,

It's the migration of the code that I am most concerned about.
Can I swap the database and keep DAO and then, as I add or change
business logic, begin to use ADO?

Trevor
 
Hi Trevor,
It's the migration of the code that I am most concerned about.
Can I swap the database and keep DAO and then, as I add or change
business logic, begin to use ADO?
Click to expand...

I am not sure. There is limited support for ADO and I don't think that DAO
is supported in any way. That said nothing prevents you to use DAO with COM
interop thing (creating a managed wrapper around non-managed COM object - VS
does this automatically, too, when you reference the COM object. However, it
is not guaranteed that it will work just like that).
 
Back
Top