December 17, 2001 at 8:54 am
If always referencing an object as dbo.<object> is a best-practice, how would onehandle qualifying objects with dbo when using an application that can run on either Oracle or SQL Server (using ODBC)? Oracle has no 'dbo' user, so referencing objects via dbo.objecname won't work in ODBC code on Oracle (unless you like getting 'table or view does not exist' errors :). You could, of course, figure out which DBMS you are connected to and use something like: if (oracle) <reference one way> else if(SQLSERVER) <reference as dbo.<object>>, but that seems like a lot unnecessary branching. I suppose you could save the object owner someplace (say the registry), but if the object-owner should change on Oracle, then there are places outside of the database that would need to be updated.
Just curious how the more experienced would implement it, or if dropping the owner from the object name is the only 'clean' way to do something like this.
Thanks all.
December 17, 2001 at 9:48 am
An interesting problem and one I've given some thought to lately as I've been doing a little MySQL work. I think the only way to build a good cross platform act is to work inside the limits of common boundaries (if your resources are limited). In this sense, you'd just drop the owner name from the query, but ensure all objects are owned by DBO.
The next best effort would be to implement branching items in your code, perhaps even in some "pre-compiler" that parses your code to make the appropriate changes for the platform. Some really neat technologies (Alpha Win32 platform, MS JVM, .NET) implement this. They make changes based on the underlying environment. Of course, this takes more resources than the first solution, but should provide better performance per platform.
The last solution requires more resources and isn't worth it IMHO, and that is maintaining two (or more) codebases.
Steve Jones
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply