| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 162.1 | | BANZAI::CAMERON | | Mon Jul 18 1988 20:06 | 54 |
| > Could someone please give me an explanation of what the
>marketing phrase "SQL Compliant" really means?
SQL compliant means nothing, or next to nothing.
What the companies are trying to say is that they are close to the
ANSI standard SQL. What they do not say is how close they are.
Nobody can say that they 'Validated', NBS has not come out with
their official validation suite. (They have given us a 'beta' version)
> Given two vendors with "SQL Compliant" databases (say Rdb and
>Oracle). Does it only mean that 3GL programs written with SQL statements
>can be compiled for either product without modification? Or does it
>mean that report writers and interactive query tools which are built
>for one "SQL Compliant" database can work with any other vendors
>"SQL Compliant" database?
Most companies that have an SQL interface have extended their SQL
implementation beyond the ANSI standard. What this means is that
if you take advantage of the language extentions offered by most
vendors, then transporting applications could be very difficult.
If you code to the standard, then migration will be much easier,
possibly transparent.
Report writers and forms are not part of the ANSI standard.
> In particular, I am wondering if a product such as Rally would be
>able to work with an Oracle database. (I know that Rally doesn't use SQL
>now, but given Digital's direction it may eventually).
I don't know anything about Rally futures, and couldn't say anything
here if I did. Call the product manager and let them know of your
requirements.
> If this can not be done, then would the best method for accessing
>other vendors "SQL Compliant" databases be to write a 3GL task for each
>and use task-to-task communications to pass SQL queries and the resultant
>information back and forth.
If you are looking at trying to glue together a product that speaks
SQL out the backend to Rdb, then you should talk to Wendy Caswell.
NOVA::CASWELL.
VAX SQL is a product that 'speaks DSRI out the back. If someone
had a DSRI compliant (there is that word again) database, they
could work together, but it would most likely fall into the
unsupported category.
Most other companies speak their own proprietary langage to their
database executive. Companies like RTI and Ingres have made these
languages SQL 'like', but not SQL.
|
| 162.2 | how do they vary from the standard ? | SNOC01::PARKER | Jeff Parker | Thu Jul 21 1988 05:24 | 5 |
| Is there available a table which lists where VAX SQL varies from
the ANSI standard ? Also one for our favorite competitor ORACLE.
Is there anything in the standard which VAX SQL & ORACLE doesn't
implement ?
|
| 162.3 | appendix b of 2.0 doc set | NOVA::CAMERON | | Thu Jul 21 1988 16:08 | 8 |
| Appendix B of the VAX SQL V2.0 Reference Manual lists the ANSI
differences that we knew about when the documentation was finalized.
Since we have gotten the NBS beta test suite we have found a few
more, but I suggest that you start there.
David Cameron
VAX SQL
|
| 162.4 | We Win | CREDIT::BOOTH | Bang the Conundrum Slowly | Thu Jul 21 1988 17:03 | 4 |
| Oracle does not implement ANSI Module Language. The new version
of VAX SQL does.
---- Michael Booth
|
| 162.5 | Exceptions and Extentions of NonStop SQL to ANSI standards | CSTEAM::WADSWORTH | KIRBY WADSWORTH | Fri Aug 12 1988 20:07 | 93 |
| I've been looking for a place to put this out. Maybe you DB heads
will be interested. This is the list of exceptions and extentions
Tandem NonStop SQL makes to the ANSI Standard. Taken from a
copyrighted work dated August 1987.
I'm afraid I won't be much good at explaining this to you.
I do not portend to be a DB expert.
Exceptions to Ansi SQL x3.135-1986
DDL level one
- Table name is a Guardian Network File Name not a legal SQL qualifier.
- Data Type cannot be approximate numeric.
- Security is controlled by Guardian, there is no support for any
Grant statement.
DDL level two
- Null Values not supported
- Create schema not supported
- User value is not supported
- Numeric data types Float, Real, Double Precision are not supported
- "Unique Constraint" not supported in create table command.
- Query specification updates have additional restrictions:
Where clause refers only to select list columns
Duplicate columns not permitted.
- Two types of views are supported
Preotection Views are updateable
Shorthand Views are not
Level Two DML
- Errors on multirecord operators may cause DATA INCONSISTANCY.
TMF must be used to ensure all changes are rolled back.
- Operation to empty set returns error instead of null value.
- Union is not supported.
- Outer Joins not possible
Extensions to the Standard
- Additional Data Types Added; Variable Length Strings, 64 bit integers
- Create Table Allows:
Key Sequenced, entry sequenced, relative files
Partitioned Tables
User defined primary keys
system generated primary keys
Default Value for each Column
Audited tables for TMF
Additional DDL statements added.
- create index
- create constraint
- alter
- drop
- comment
- update statistics
Operational Locks
- Browse access
- Stable access
- Repeatable access
DCL statements added
Lock / Unlock Table
Free Resources
Control Table
Limits
16 Base Tables per view
4096 byte block size
|
| 162.6 | xref summary of SQL standards world | BISTRO::WATSON | the disk has shrunk again | Wed Aug 17 1988 10:33 | 6 |
| Those following this note will, I'm sure, also be interested in note 192.1
in the SQL conference.
Hit KP7 if you want to add this conference to your notebook...
Andrew.
|