Hi

I'm in the process of designing a modular application where each module (in a DLL) will need access to the database. The database is LOCAL and I have the standard VCL version of EDB.

My original thinking was that I woudl just create a TEDBDatabase & Session in each module, and everything woudl be fine, but now I've searched these forums I'm not so sure.Will this design fail at 5 modules due to the limitations of the Standard VCL edition?

How do others implement EDB access in a moduler application?

Is it possible to pass the session from the host to the modules?  I've tried this but I get an exception when I open tables saying that the Session name is not valid, so if it's possible, I'm not doing it right and would appreciate some pointers please (pun intended

Cheers
Shane

On 11/16/2014 5:09 PM, Shane Sturgeon wrote:
> My original thinking was that I woudl just create a TEDBDatabase & Session in each module, and everything woudl be fine, but now I've searched these forums I'm not so sure.Will this design fail at 5 modules due to the limitations of the Standard VCL edition?

Sounds good.

The 5 connection limit is for the server (C/S) that's included with the
VCL standard and not for local file connection.

As long as your definition of local means "direct local file access"
there are no connection limits.

Raul

Raul wrote:

> The 5 connection limit is for the server (C/S) that's included with the
VCL standard and not for local file connection.

As long as your definition of local means "direct local file access"
there are no connection limits.

Thanks Raul - good to know.  It's single user on local machine with a connnection to the config file. I don't start the edb server app (didn't even know it was there until your post promtoed to take a look) so I guess all the files are being accessed directly.

I am still a bit worried that the session/DB in each module is "wasteful" but the modular aspects of the design are key, so at least I know I can proceed with EDB in the mix.

Cheers
Shane

On 11/16/2014 6:07 PM, Shane Sturgeon wrote:
> I am still a bit worried that the session/DB in each module is "wasteful" but the modular aspects of the design are key, so at least I know I can proceed with EDB in the mix.

Shane,

This might be true based on planned usage but i would say best practice
is to do it the way you are planning.

To be thread safe you must have unique components anyways (session, db,
table, query etc) so having separation up-front in design means you
never have to worry about this later.

In your case since you're planning on using DLLs you will have another
complication in that the class layout (and i think memory management)
are separate between exe and dll so you should not be passing delphi
objects around to being with (i.e. session created in exe should not be
passed to DLL to use, etc). It's a delphi object model limitation.

So keeping things completely separate will help you in long term.

Raul

Thanks Raul

>To be thread safe you must have unique components anyways (session, db,
table, query etc) so having separation up-front in design means you
never have to worry about this later.

There are some actions which may take a while to complete, and I have been contemplating doing them in a thread. I've not done any substantail thread coding before, so even if the thread is kicked off in the host application, will I need to give it another Session & DB component for the duration?

On 11/16/2014 8:39 PM, Shane Sturgeon wrote:
> There are some actions which may take a while to complete, and I have been contemplating doing them in a thread. I've not done any substantail thread coding before, so even if the thread is kicked off in the host application, will I need to give it another Session & DB component for the duration?
>

Yes and for each thread (in addition to in the main thread). Usually
you'd create the session, db,table etc in the thread to keep it simpler
to manage. See "Multi-threaded Applications" section in the manual:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2&product=rsdelphiwin32&version=XE7&topic=Multi_Threaded_Applications

Raul

Will check that out.

Thanks for your help Raul

Cheers
Shane

Shane


I support what Raul has said, especially the not trying to share the session across the application/dll boundary. Its many years since I bothered about dlls so I'm way out of date. Depending on what you are trying to achieve, level of skill, ease of maintenance and distribution etc you may want to consider the use of packages rather than dlls.

If its for internal use you may also want to think about making it just one big app with access controlled by user access rights. If you're selling it and allowing people to buy various capabilities then switching functionality on/off is much easier using packages or dlls but still achievable with one major app.

In my case I moved from dlls to a single .exe which excluding MadExcept and FastMM in full debug mode comes in at about 15Mb


Roy Lambert

Roy Lambert wrote:

>If you're selling it and allowing people to buy various capabilities then switching functionality on/off is much easier using packages or dlls but still achievable with one major app.

>In my case I moved from dlls to a single .exe which excluding MadExcept and FastMM in full debug mode comes in at about 15Mb

Thanks Roy,

I've thoguht about packages and decided against them. I am aware of the difficulties and hence are designing the appliation so that the "modules" can be loaded externally or from forms linked into the EXE. This is so that I can easily identify DLL related issues but also so that I can follow your advice and actually see whether the effort is worth shipping the DLLs. One benefit is that it forces me to be loosely coupling all the "modular" areas which is also useful.

Cheers
Shane

On 11/18/2014 4:34 AM, Shane Sturgeon wrote:
> One benefit is that it forces me to be loosely coupling all the "modular" areas which is also useful.

Shane,

One more thing I'd suggest you check out is navigation coordination and
change detection (if you haven't already). Since you're using separate
components for every module you might need to make sure modules "update"
their display data in sync as well as get notified when data has been
changed (by another module_  i don't know anything about the app or
modules so this might be non-issue.

Raul