FAQ: v7.1
Date: 28 Nov 1994 23:59:31 GMT
Message-ID: <3bdqt3$i6f_at_aggedor.rmit.EDU.AU>
What follows below the form feed are some notes on Oracle 7.1 issues. Though not really ready, it still could be useful.
ORACLE VERSION 7.1 $Date: 1994/11/24 09:46:37 $
$Revision: 1.2 $
$State: Exp $
Revision Log
This section covers some of the features announced for version 7.1 of the Oracle RDBMS.
- ANSI SQL + FIPS ANSI-SQL Compliance Levels + FIPS Compliance Checking + Column AS Alias
- DBA Issues + New Server Manager + Read-Only Tablespaces + Support for CONNECT INTERNAL + Oracle Names + Parallel Processing + Blank Trimming initialization parameter
- General Issues
+ Package for Dynamic SQL
+ Multiple triggers
+ Order by column alias
+ PL/SQL Functions in SQL
FIPS ANSI-SQL Compliance Levels
Oracle RDBMS 7.1 permits FULL compliance with FIPS SQL-89 and ENTRY-level compliance with FIPS SQL-92. Some aspects are pushing into TRANSITION-level compliance.
Top of File
FIPS Compliance Checking
A parameter called FIPS is available (I don't know whether this is instance or session, but I suspect session) that when turned on will bitch about any non-ANSI construct.
This will permit you to validate your applications for standards, for example example if you want to migrate an Oracle application to a non-Oracle RDBMS. (But why would you want to do something that stupid).
As some of the best parts of Oracle (such as DECODE) are non-ANSI, this is usually going to be annoying when turned on.
Top of File
Column AS Alias
From 7.1 (and later versions of 7.0) you can use the ANSI method of
declaring column aliases, which you will be familiar with if you are
using products such as Sybase or MS-Access. The "old" Oracle method
was as follows:
select ENAME, SAL / 12 MONTHLY_SALARY from EMP;
The ANSI method, which I actually prefer because it makes the parser in my head work better is as follows: select ENAME, SAL / 12 as MONTHLY_SALARY from EMP;
New Server Manager
A new all-singing all-dancing GUI replacement for sqldba is being introduced. Support for sqldba (especially lmode=y is gradually being withdrawn. This really worries me. I want to be assured that :
- I can to DBA functions when I have few resources, such as when the machine is in single user mode, X-window directories are on unavailable partitions, etc.
- I can run DBA functions from scripts, especially through pipes. Currently it appears that sqldba goes into lmode=y automagically when being driven from a pipe. Thank goodness.
I could probably complain more about potential worries. Contact your local Oracle people today and express your concerns. I see this as causing a bigger protest than the no-INP file for Forms 4 ruckus. BUT linemode is still supported on all platforms with v7.1.3.
Top of File
Read-Only Tablespaces
Read-only tablespaces are being introduced. When you make a tablespace read only, you can improve performance, prevent most writes to the data (objects can be dropped, of course, because this only requires writes to the data dictionary in the SYSTEM tablespace) and will probably eventually support databases on CD-ROM. The control files note the latest logfile number required for the tablespace.
Top of File
Support for CONNECT INTERNAL
Support for connect internal is being withdrawn. This is not a bad thing, and the workaround depends upon operating system group memberships.
Top of File
Oracle Names
A new facility is being introduced to help standardize names. I think this mainly deals with distributed environments.
Top of File
Parallel Processing
Utilities such as recovery, export/import and loading will become parallelized with some architectures. Communication will apparently occur through the SGA so you'd better make this MUCH bigger.
Top of File
Blank Trimming initialization parameter
A new initialization parameter BLANK_TRIMMING which can take the values true or false permits assignment of string values to a short target from a longer source when TRUE. If this parameter is FALSE such assignments are disallowed.
Top of File
Package for Dynamic SQL
A new DBMS package permitting the generation of SQL on the fly will be available, probably called DBMS_SQL. I am told this will permit not only EXEC SQL type statements (such as update and delete) but also select. (So what are you going to select INTO, I ask?)
Top of File
Multiple triggers
Whereas with v7 only one trigger of any type can exist on a table, with 7.1 this restriction is removed. For example, you could have two post-insert triggers, each updating another audit table. This, in my opinion, should be AVOIDED. The order in which the triggers fire is not guaranteed (and why should it?) and I think it will only lead to confusion. I'd stick to only allowing one trigger of each type in MY databases, whether Oracle permits more or not.
Top of File
Order by column alias
With 7.1 you can use a column alias as an expression in the order by clause of an SQL statement. This means you do not have to use the column number for ordering. (You should still use column number when you are using set operations such as union - apart from this you are discouraged from using column number.)
An SQL statement using this facility looks like this:
select EMP_ID, (EMP_SAL * EMP_BONUS) as EMP_REMUNERATION
from EMP
order by EMP_REMUNERATION;
Top of File
PL/SQL Functions in SQL
Database functions written in PL/SQL can be used in SQL statements. This is a big advantage. This could be particularly useful in combination with the new dynamic SQL package and DBMS pipes. Application design and control can be really tightened up. As a trivial example, you could write a function that decodes a particularly nasty code. (This could be the encoding of system object types in the OBJ# internal table, for example). Simply write the function once, document it and make the doco available to other application designers and then everyone can easily use it in their SQL. And when you change the core function (and recompile it) everything flows through. Bliss.
However, I can see some restrictions. If Oracle have been lazy, then you won't be able to select from within such a function. I would complain about this. However, if they merely prohibit database updates from inside such functions, then that is fair enough, and possibly a good thing. Such "side-effects" could be considered pathological.
Top of File
Revision Log
Back to top of file
$Log: v7_1.html,v $
# Revision 1.2 1994/11/24 09:46:37 dtb # Corrections and additions # # Revision 1.1 1994/11/23 16:55:38 dtb # Initial revision # Back to top of file
_________________________________________________________________
-- --- David T. Bath | dtb_at_ftp.bf.rmit.edu.au 3/153 Wattletree Rd | Snr Tech Consultant, Global Consulting Services MALVERN 3144 VIC | 179 Grattan St, Carlton, Vic 3053, Australia +61 3 500 9337 | Ph: +61 3 347 7411 Fx: +61 3 347 0182 WWW pages incl. ORA FAQ: lynx http://www.bf.rmit.edu.au/~dtbReceived on Tue Nov 29 1994 - 00:59:31 CET