[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 222
  • Last Modified:

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.
0
ajm411
Asked:
ajm411
1 Solution
 
ajm411Author Commented:
Edited text of question
0
 
MaDdUCKCommented:
pass pointers between the two...
0
 
danny_pavCommented:
don't forget to synchronize the use
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
altenaCommented:
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
0
 
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.
0
 
TheGrinchCommented:
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.
0
 
TheGrinchCommented:
No comment -- I just forgot to check the notify box.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now