Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 6 of 6 total |
Server side procedures |
Thu, Apr 27 2006 2:35 AM | Permanent Link |
"Edhrx" | Hi
We are the start of a large project and decisions are being made about methodogies being used . We intend to put as much buisness logic as possible on the server, but minimise alterations to the server code. Is there any sense in putting the buisness logic into a dll and then calling the different functions from a single procedure in the dbisam server. The dll function name would be comming in as a parameter. Further, should the dll be loaded when the server starts or should it get loaded on demand , that is , only when a function in the dll is called. All advice appreciated Ed. |
Thu, Apr 27 2006 11:05 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ed,
<< Is there any sense in putting the buisness logic into a dll and then calling the different functions from a single procedure in the dbisam server. The dll function name would be comming in as a parameter. Further, should the dll be loaded when the server starts or should it get loaded on demand , that is , only when a function in the dll is called. >> That would be fine, however, it will prevent you from passing direct object references, long strings, etc. to the DLL, which may or may not even be an issue. The upside is that you can easily replace the business logic as needed without downing the server. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Apr 27 2006 11:57 AM | Permanent Link |
"Edhrx" | tim,
would this be feasible / legal on client software starttransation Edit Record Post if not (server procedure) Then Rollback Else commit; The dll procedure itself dll procedure starttransation dll procedure do some database activity if ( Error ) begin dll procedure rollback; Result:= False; end else begin dll procedure commit; Result:= true; end; Ed.... "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:ABF2AC8C-7779-4EBA-A1DE-78DB7444326C@news.elevatesoft.com... > Ed, > > << Is there any sense in putting the buisness logic into a dll and then > calling the different functions from a single procedure in the dbisam > server. The dll function name would be comming in as a parameter. Further, > should the dll be loaded when the server starts or should it get loaded on > demand , that is , only when a function in the dll is called. >> > > That would be fine, however, it will prevent you from passing direct object > references, long strings, etc. to the DLL, which may or may not even be an > issue. The upside is that you can easily replace the business logic as > needed without downing the server. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Fri, Apr 28 2006 3:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ed,
<< would this be feasible / legal >> No, the two transactions will interfere with one another since the trigger transaction will considered part of a separate session and will have to wait until the client transaction finishes. However, if you simply leave out the transaction processing in the DLL it will work just fine, or you could do a transaction check before calling the DLL and commit/rollback the transaction as necessary after the DLL call and the response from the DLL is returned. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Apr 29 2006 9:58 AM | Permanent Link |
"Edhrx" | Tim
If I am running tdbisamqueries in the dll would I able to pass in the TdbisamSession Object sent into the trigger ? Or Should I just 'roll my own' in the dll Ed.. "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:3A226E9C-BEBD-4A0F-B1EC-A9C1BB0D9B1E@news.elevatesoft.com... > Ed, > > << would this be feasible / legal >> > > No, the two transactions will interfere with one another since the trigger > transaction will considered part of a separate session and will have to wait > until the client transaction finishes. However, if you simply leave out the > transaction processing in the DLL it will work just fine, or you could do a > transaction check before calling the DLL and commit/rollback the transaction > as necessary after the DLL call and the response from the DLL is returned. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Mon, May 1 2006 2:31 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ed,
<< If I am running tdbisamqueries in the dll would I able to pass in the TdbisamSession Object sent into the trigger ? >> No, that's the problem with using a DLL - you can't pass any objects or long strings/arrays back and forth. A runtime package, on the other hand, can be used in such a manner. << Or Should I just 'roll my own' in the dll >> If you use a separate session, then you will have a transaction locking conflict because the new session will have no knowledge of the existing client session's transaction state. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, April 19, 2024 at 07:09 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |