Re: Insert a new row into a talbe using Addnew method via Oracle OLEDB Provider

vslabs_at_onwe.co.za (Billy Verreynne) wrote in message news:<1a75df45.0307230029.51fa4273_at_posting.google.com>...
> rooty_hill2002_at_yahoo.com.au (Gary) wrote
>
> > I am writing a Oracle database connection layer (a VB class using
> > Oracle OLEDB provider) for my vb developers. I have a little problem
> > here, see whether you have some idea about it.
> <snipped>
>
> Gary, I would chuck VB out of the window as the layer to use to
> provide that type of data class abstraction. Instead, I would select
> PL/SQL.
>
> The most simplistic of implementations : create a PL/SQL package per
> table. Treat the package as a persistant class. Define "methods" for
> this class as stored procs and functions within the package. AS PL/SQL
> supports polymorphisism, it works pretty well as you can "overload"
> methods within a package. You may also want to have a look at methods
> (aka functions) that can return reference cursors (similar to a
> Transact SQL stored proc that does a SELECT and returns a result set).
>
> Advantages are numerous even with this simplistic approach. To mention
> a few:
> - network traffic is reduced (up to 80% from personal experiece)
> - no SQL in the client (your VB programmers can do the job without
> being Oracle SQL experts)
> - exposing an API of sorts to your programmers (of which the
> implementation is hidden) instead of Oracle SQL and physical db
> structures & issues
> - allowing you to refactor (and finetune) the API implementation
> mercilessly without having to change a single line of VB code and
> redeploying the client app
> - business logic moved to the database (where it should be)
> etc.
>
> Ideally, the VB code should deal with information presentation logic,
> basic validation, and process flow. Anything more than that can be
> done better on the database side.

Billy,

I totally agree with you on this point and appreciate your suggestions. Thanks.

I actually I have discussed with development team to move the business logic to the server as much as posible. It will happen later on here. At the moment, 80% of the basic logic reside on our middle tier (quite heavy one) and we don't have time to move and test them and the management doesn't want to take the timing related risks because the database upgrading project is just one part of a hugh project which has strict deadline on it.

Thank you again.

Gary Received on Wed Jul 23 2003 - 18:55:17 CDT