Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 10 total |
Modular App & DB Access |
Sun, Nov 16 2014 5:09 PM | Permanent Link |
Shane Sturgeon | 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 |
Sun, Nov 16 2014 5:31 PM | Permanent Link |
Raul Team Elevate | 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 |
Sun, Nov 16 2014 6:07 PM | Permanent Link |
Shane Sturgeon | 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 |
Sun, Nov 16 2014 6:57 PM | Permanent Link |
Raul Team Elevate | 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 |
Sun, Nov 16 2014 8:39 PM | Permanent Link |
Shane Sturgeon | 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? |
Sun, Nov 16 2014 9:15 PM | Permanent Link |
Raul Team Elevate | 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 |
Sun, Nov 16 2014 10:38 PM | Permanent Link |
Shane Sturgeon | Will check that out.
Thanks for your help Raul Cheers Shane |
Mon, Nov 17 2014 5:16 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Nov 18 2014 4:34 AM | Permanent Link |
Shane Sturgeon | 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 |
Tue, Nov 18 2014 12:01 PM | Permanent Link |
Raul Team Elevate | 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 |
This web page was last updated on Saturday, June 22, 2024 at 05:51 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |