Re: Moving from MS to Oracle

Why not code a data access layer DLL that the interface layer uses. The data access layer can then implement database-specific commands to optimize your application for either. There are significant coding differences between Oracle and SQL Server that coding for the lowest common denominator will not produce the responsiveness you are looking for, such as the Oracle provider's lack of support for updatable serverside  cursors and resultset returning stored procedures.

If you code a data access layer in the form of a DLL, then you can update the DLL depending on which database server they are using and the change is invisible to the interface layer. Then you can take advantage of the different mechanisms that each provides to make your app as fast as possible while not requiring any change to the interface.

Kirk Allen Evans
kaevans_at_yahoo.com

In article <memo.20000307191232.16279H_at_terra.compulink.co.uk>,   phatcher_at_terra.cix.co.uk wrote:
> One major gotcha is that Oracle is case-sensitive and there's no way
> of turning it off, so all your searching fields need to flipped to
 one
> case or the other to get 'nice' behaviour.
>
> The route we've taken is to code generic SQL, using the ODBC escape
> features, holding this in the data tier rather than stored procs so
> that the only thing needed on the server is the schema.
>
> Another nasty is that Oracle still don't support ANSI join syntax and
> there are problems in all the drivers in generating the required
> Oracle syntax - primarily to do with nested outer joins so it may not
> hit you.
>
> Regards
>
> Paul Hatcher, MCSD
> Principal Consultant
> Graduate Associates Ltd
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Mar 08 2000 - 00:00:00 CST