Hi,

we still use DBISAM because we have a huge server-application (windows service application) with a DBISAMEngine-component which uses database triggers. The triggers calculate different very complex things and this is all done with C++Code (because we are using C++Builder).

Since we are having an active maintenance-contract for ElevateDB I looked at the ElevateDB-components once again but it still seems to be that there are no trigger-events I can handle with C++ code as I were able with DBISAM. Rewriting all the code in SQL-Code is not an option because of the complexity of all that...

Is there a way to use our existing c++ trigger-codes in ElevateDB?

I wonder how other people handled this when they moved from DBISAM to ElevateDB...

Regards,
Robert

Robert


You will have to write some SQL, but the biggest thing you'll have to do is decide where to put the triggers. I don't know about C++ code cos I use Delphi but here's an example

TRIGGER "FormatPhoneNumbers"
BEGIN  
IF NOT NEWROW._MainPhone IS NULL THEN
IF REPLACE(' ','',NEWROW._MainPhone) = '' THEN
  SET NEWROW._MainPhone = NULL;
ELSE
  SET NEWROW._MainPhone = FormatPhoneNo(NEWROW._MainPhone);
END IF;
END IF;
IF NOT NEWROW._SecPhone IS NULL THEN
IF REPLACE(' ','',NEWROW._SecPhone) = '' THEN
  SET NEWROW._SecPhone = NULL;
ELSE
  SET NEWROW._SecPhone = FormatPhoneNo(NEWROW._SecPhone);
END IF;
END IF;
END

FormatPhoneNumber is a Delphi function (slightly over 100 LOC) which has been registered as an external function with ElevateDB. Providing your C++ functions can be called from Delphi I see no reason why it shouldn't work. At worst you would (I think) have to adapt Tim's template to allow you to build a dll using only C++.

Have a look in the binaries ng for some examples of external functions.

Roy Lambert [Team Elevate]

Hi,

is there an other way than extracting the functions do a dll? We want to have all the code in our server-application like we have this right now in DBISAM, cause it's a very complex code and there have to run some other threads all the time in the same application...

Regards,
Robert

...and what's the reason the ElevateDB-Engine-Component does not have a simple trigger-event anymore?

Robert

>is there an other way than extracting the functions do a dll? We want to have all the code in our server-application like we have this right now in DBISAM, cause it's a very complex code and there have to run some other threads all the time in the same application...

Not that I'm aware of. If you have the source and feel brave you could modify that, you could also try customising the server.

Roy Lambert [Team Elevate]

Robert

>..and what's the reason the ElevateDB-Engine-Component does not have a simple trigger-event anymore?

Tim is the only one that can supply an official answer, but my understanding is that partly it was driven by requests to have DBSys able to run the same triggers as apps. In my case I have some custom stuff in one app that means I can't use DBSys to edit data without having to do a full repair on the table(s) afterwards. It was probably also driven by Tim's determination to adhere to the SQL standard. Having triggers built into the engine as well would mean you could have two sets of triggers in conflict with each other. Its bad enough sometimes having component events messing each other up without the database joining in the fun.

Roy Lambert [Team Elevate]

Robert

>is there an other way than extracting the functions do a dll? We want to have all the code in our server-application like we have this right now in DBISAM, cause it's a very complex code and there have to run some other threads all the time in the same application...

Reading the above again there are a few more comments:

1. Like yourself I wanted to have a single .exe which the need for a dll messes up. However, the benefits of the approach are sufficient that its worth doing, and I started to need dlls anyway due to adding in ssl to the email part of the app.

2. The complexity of the code doesn't matter wether its in a dll or an exe. What is needed with a dll is a different approach to testing. Eg I wrote a small test bed app for my text generator. However, as a bonus EDBManager can now also be used as a test bed for the functions in the dll.

3. If the database is being accessed in a thread then you have to do nothing more to access the dll - ie make sure its known to ElevateDB when the engine starts up. If the functions are being accessed outside of ElevateDB then its simply a matter of loading the dll and calling the functions.

There are areas where I did and still do think Tim could have been nicer to people moving from DBISAM, but this isn't one of them.

Roy Lambert [Team Elevate]

Robert,

<< ..and what's the reason the ElevateDB-Engine-Component does not have a
simple trigger-event anymore? >>

Roy is correct - the reason for requiring external modules now for native
code is two-fold:

1) It removes the requirement of re-compiling the core application whenever
the trigger/custom function code changes

2) It allows for all interfaces - ODBC, .NET, and Win32/64 to use the same
external module code

--
Tim Young
Elevate Software
www.elevatesoft.com

Robert,

<< Is there a way to use our existing c++ trigger-codes in ElevateDB? >>

Yes, but you'll have to put them in an external module along with some
external function/procedure definitions in order to do so:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=External_Modules

I can send you a copy of a C++ external module template project that you can
use for this.  Currently, we only ship Delphi template projects with
ElevateDB.  If you're interested, just send me an email
(timyoung@elevatesoft.com) and I'll reply with the project code.

--
Tim Young
Elevate Software
www.elevatesoft.com