How to design a VC++/MFC database application

I'm trying to design a telecommunications network planning application. The user will enter network data through various dialogs and, in response to clicking Save on the File menu, it will be stored in a MS Access database. In response to a menu pick, algorithms to perform some analysis on the network will be invoked, and will run as threads. The output will also be stored in database tables, and displayed through reports.
The main application will be built as an AppWizard exe.
I plan on creating an MFC extension DLL containing a class derived from CRecordset for each table in the database. (I'd like to have them in a DLL so that other applications could also use them.) Another DLL will contain the functions to perform the analysis. Only one of these functions will be directly invoked from the main application and it will be a thread function.
My question is, how do I set this up so that both the main application and the thread function in the DLL can access the data? That is, I'd like the CRecordset objects to be created in the main application but available to the thread function. I'm not sure whether the CDatabase object and CRecordset objects should be members of the view or document class in the main application, or should they be defined as globals in the app class.
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

TheGrinchConnect With a Mentor Commented:
The CRecordset classes should go in your Document class, and should all share a single database connection. That is, create a CDatabase object and use it when constructing the CRecordsets.

The thread should create a different database connection, and instantiate a separate set of CRecordset objects using this connection.

There is no advantage to having a single set of CRecordsets. They will be defined only once, but instantiated twice. Sharing a single set between the main App and the thread introduces many complexities but offers no gain.

Your design is reasonable.
ajm411Author Commented:
Edited text of question
pass pointers between the two...
Never miss a deadline with

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

don't forget to synchronize the use
This sounds like a real bad idea to me....

Ill explain:
The document/view framework is just a way to look ar data.
It is a bad idea to have all sorts of threads running aroung
accessing this data, (recordsets or something else)
The synchronisation problems will kill the app.

The idea to componentize the app is a good one, but your
components should be based on "objects" in stead of tables.

Think this one over real good, separate the DB-work from the C++ work. and build a good object model FIRST.

Good Luck
ajm411Author Commented:
While Altena did a good job of explaining why the design assumption I made was a bad one, not much was offered as far as an alternative.

I had considered the suggestion to use my own objects rather than CRecordset derived objects in the thread function. If I do this, I'm still not sure where to define these objects so that they are accessible by:
1.) the doc class of my main app, where they will be populated from the CRecordset derived objects (the doc class will own the CRecordset derived objects) and
2.) the thread function (or even just a regular function) in a separate DLL containing the algorithms.
No comment -- I just forgot to check the notify box.
All Courses

From novice to tech pro — start learning today.