Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Server side procedures
Thu, Apr 27 2006 2:35 AMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image