I am aware of Oracles Outer join syntax problem.
Our product is purchased by state agencies. In most cases, they have
specific requirements for database back-end. Being compliant with Oracle and
MS SQL Server is pretty important. We have most of the SQL code isolated, so
if we have to make changes to one or two of our back-end components that are
specific to the database, I'm fine with that. For one thing, we have a
program that actually creates the tables for our system. That, of course,
must be database specific.
We have only one component that relies on the outer join syntax, and it's in
a very isolated piece of code, so doing an Oracle specific version is not a
big deal.
As for the GO stuff, I kinda figured that was the case. Thanks.
Pete
----- Original Message -----
From: "Darin Strait" <dstrait@e...>
To: "sql language" <sql_language@p...>
Sent: Sunday, July 08, 2001 3:58 PM
Subject: [sql_language] Re: the GO command
> GO is a batch delimiter for Microsoft's query tools, such as ISQL, ISQLW,
> OSQL and Query Analyzer. It is not ANSI. It's my understanding that ANSI
> specs are large, unwieldy and expensive. Perhaps you could try
Bookpool.com
> or Amazon.com.
>
> IMO, you won't be able to be compliant with Oracle unless they have fixed
> their outer join syntax to be ANSI compliant.
>
> Just to play the devil's advocate: What is the point of being compliant?
Are
> you planning for possible future ports or are you planning to be
> multi-database? Do you understand what you give up by not using the
specific
> features of the databases that you run on?
>
> HTH,
> Darin Strait, MS SQL Server Development and Administration
> http://home.earthlink.net/~dstrait/professional/resume.htm
>
>
> ----- Original Message -----
> From: "Pete Davis" <pdavis@q...>
> To: "sql language" <sql_language@p...>
> Sent: Thursday, July 05, 2001 10:30 AM
> Subject: [sql_language] the GO command
>
>
> Is the "GO" command in SQL ANSI or is it Microsoft SQL specific? Where can
I
> find the specs for ANSI?
>
> We're trying to keep our application ANSI compliant as much as possible.
We
> have certain very specific areas where it isn't, but we can make changes
in
> those specific areas to support other database engines. In particular,
we're
> trying to be compliant with both MS SQL Server and Oracle. We hope to be
> compliant with all major engines, though.
>
> Pete
>
>
>
>