Re: [DUG] Database Abstraction Layer

Sun, 15 Aug 2004 16:34:18 -0700 

Steve

I use both methods, usually the Stored Proc route when updating from a Web Page
but it becomes unweildy in an app with 100's of tables

Recently I wrote my own resolver in PHP for a web page (PHP's 'array' handling of
Input data is fantastic) so I'm doing that instead of stored procs.

I've only had niggles with kbmMemtable its pretty straight forward


Neven MacEwan (B.E. E&E)
Ph. 09 621 0001 Mob. 0274 749062



Witherden, Stephen wrote:

That's a good point, we are moving more and more of our data access routines 
(especially the complex stuff) into the database itself.

And by the time Yukon comes out you can write C# in the database!

However, as a developer, I start feeling more and more out of touch with the business 
logic the further it gets embedded in the database.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Traci Sumpter
Sent: Monday, 16 August 2004 10:53 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Database Abstraction Layer


I found using the kMemTables were twice as much work as necessary and had
major difficulties when changing versions of Delphi.

When working with SQL Server we found creating stored procedures for
updating, insert and deletions were effective over a network (reduces
traffic) and also let SQL Server do the work and not the client/layer

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Neven MacEwan
Sent: Monday, 16 August 2004 9:43 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Database Abstraction Layer


Stephen

After getting frustrated with ADO/SQL Server Resolver Logic I moved to
kbmMemTable as an  in-memory
table (loaded from ADO/MSSQL) and then wrote an applied my own update
code (using the kbmMemTable transactions
and resolver).

I found the advantage of this is that I controlled how record were
loaded and updated, you could apply the same logic (I
left 'stubs' for DB Specific requirements but have had no need to use
them), I doubt a 'query' generator would do what
you want you'll be frustrated by the subtle differences between databases.

I'd also suggest you look at xcase www.xcase.com as a cost effective
tool for designing and maitaining different DBMS

I'm happy to show you the code, Its v simple

Neven MacEwan (B.E. E&E)
Ph. 09 621 0001 Mob. 0274 749062



Witherden, Stephen wrote:



Dear All

We have a number of COM objects written in Delphi accessing a SQL Server


database using ADO. The COM objects execute the SQL statements through a
database object which essentially uses ADO's connection object to run the
SQL and return recordsets etc.


So in other words, stock standard active-record (Fowler).

We've decided to make the above COM objects database agnostic. In


particular, we want to be able to run on all the big names (SQL Server,
Oracle, Postgres etc).


Obviously, one option is to write a fully functional data-mapper layer


(Fowler again) ourselves but before we jump down that path I thought I would
best open the question up to the forum:


Are there any mature open source / commercial database abstraction layers


for Delphi and/or .Net that anyone recommends? It has to work with existing
objects and database of course.


I am not looking for an Object-Relational mapper or a code generator per se


although I suppose that is one solution. I am rather looking for a layer
that allows me to flick a switch and move from one database environment to
another. For example, a query generator would suit fine.


I know this is kind of like asking "what is the meaning of life" from a


programming perspective but I am keen to hear simple solutions to this
complex problem :)


Stephen

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi






_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi




_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi

Reply via email to