Hi LLBLGenPro nerds,

I'm trying to find out if there are books or guides, howto write code (with LLBLGenPro) to accomplish the same task (in our case persist business objects) with different databases (MSQQL, Orcale, ...).

Till now we are using the MSSQL but our customers ask again and again for support of Oracle.

Any comments?

Thanx

Christoph

migrate your schema to oracle (same order of fields) create an llblgen pro project from that generate adapter code (I hope your sqlserver code is also adapter) throw away the db generic project as you share that with sqlserver instead of instantiating the DataAccessAdapter class from the SqlServer dbspecific project, you do that from the Oracle specific project.

Now your app should run on oracle.

Of course, a lot of things can go wrong, for example you used sqlserver specific types like GUIDs. Keep the names of the entities in the oracle project the same as the sqlserver project, keep the fields in the same order.

Hi Otis,

thanx for your quick answer.

My main concern is the part which is normally inside the database like views, functions, stored procedures, triggers, ...

Normally a lot a things is done inside the database, like consistency checks, actions on delete, insert and update, functions which gather values for views and so on.

The question is how to I move this code into the layer whithout to much performance loss in a scenario where many clients access the database directly.

And yes, I do use Guids as PK because they make in our scenario life easier ;-)

ChBaeumer wrote:

My main concern is the part which is normally inside the database like views, functions, stored procedures, triggers, ...

Normally a lot a things is done inside the database, like consistency checks, actions on delete, insert and update, functions which gather values for views and so on.

If you have them now inside SqlServer, you of course have to move them towards Oracle as well.

The question is how to I move this code into the layer whithout to much performance loss in a scenario where many clients access the database directly. And yes, I do use Guids as PK because they make in our scenario life easier ;-)

Triggers should be ported, as doing things outside the DB in a trigger like way can be cumbersome. consistency checks and the like can be moved towards the BL tier, you probably lose some cycles due to the move of data outside the DB but that shouldn't be much.

GUIDs are a problem, Oracle doesn't have a type which can mimic them, the most likely candidate is a varchar2 but that's not that optimal.