| timbo@cvs.perl.org 2005-06-03, 8:27 pm |
| Author: timbo
Date: Mon May 9 07:26:24 2005
New Revision: 1045
Modified:
dbd-oracle/trunk/Changes
dbd-oracle/trunk/MANIFEST
dbd-oracle/trunk/README.vms
Log:
Credit whwre it's due.
Add new test to MANIFEST.
Change line-endings of README.vms (umm, old change, can't remember why)
Modified: dbd-oracle/trunk/Changes
====================
====================
====================
==================
--- dbd-oracle/trunk/Changes (original)
+++ dbd-oracle/trunk/Changes Mon May 9 07:26:24 2005
@@ -8,11 +8,11 @@
Changed Makefile.PL to improve build rule detection.
Changed README.vms re logical name tables thanks to Jakob Snoer.
Changed README.aix thanks to Stephen de Vries.
- Changed "Binding Cursors" section of docs, clarifying examples.
+ Changed "Binding Cursors" docs, clarifying examples thanks to Charles Jardine.
Added VMS logical name checks to Makefile.PL thanks to Jakob Snoer.
Added "Trailing Spaces" section to docs thanks to Michael A Chase.
- Added support for nested cursors in select lists.
+ Added support for nested cursors in select lists thanks to Charles Jardine.
=head1 Changes in DBD-Oracle 1.16 (svn rev 515) 22nd October 2004
Modified: dbd-oracle/trunk/MANIFEST
====================
====================
====================
==================
--- dbd-oracle/trunk/MANIFEST (original)
+++ dbd-oracle/trunk/MANIFEST Mon May 9 07:26:24 2005
@@ -64,6 +64,7 @@
t/31lob.t
t/40ph_type.t
t/50cursor.t
+t/55nested.t
t/60reauth.t
t/70meta.t
t/nchar_test_lib.pl
Modified: dbd-oracle/trunk/README.vms
====================
====================
====================
==================
--- dbd-oracle/trunk/README.vms (original)
+++ dbd-oracle/trunk/README.vms Mon May 9 07:26:24 2005
@@ -1,87 +1,87 @@
-=head1 README.vms for DBI and DBD::Oracle
-
-Date: Wed, 15 Sep 2004 11:44:09 +0300
-From: Jakob Snoer <jakob.snoer@dk.ibm.com>
-
-This is related to Oracle RDBMS 9.2 and later, since Oracle
-made fundamental changes to oracle installation requirements
-and factual installation with this release.
-
-Oracle's goal was to make VMS installation be more like on
-*nix and Windows, with an all new Oracle Home structure too,
-requiring an ODS-5 disk to install Oracle Home on instead of
-the good old ODS-2.
-
-Another major change is the introduction of an Oracle generated
-logical name table for oracle logical names like ORA_ROOT and all
-its derivatives like ORA_PROGINT etc. And that this logical name
-table is inserted in LNM$FILE_DEV in LNM$PROCESS_DIRECTOR
Y.
-
- (LNM$PROCESS_DIRECTO
RY)
-
- "LNM$FILE_DEV" = "SERVER_810111112"
- = "LNM$PROCESS"
- = "LNM$JOB"
- = "LNM$GROUP"
- = "LNM$SYSTEM"
- = "DECW$LOGICAL_NAMES"
-
-This ensures that any process that needs to have access to
-oracle gets the environment by just adding one logical name table
-to a central process specific mechanism.
-
-But as it is inserted at the very top of LNM$FILE_DEV it also
-represents a source of misfortune - especially if a user with
-enough privilege to update the oracle table does so (presumably
-unintentionally), as an examble by changing NLS_LANG.
-
-PERL has the abillity to define, redefine and undefine (deassign)
-logical names, but if not told otherwise by the user does it
-in the first table in above list, and not as one would normally
-expect in the process table.
-
-Installing DBI and DBD::Oracle has influence upon this since in
-both cases a few enviroment variables are read or set in the
-test phase.
-For DBI it is the logical SYS$SCRATCH, which is a JOB logical.
-For DBD-Oracle it is when testing a new feature in the Oracle
-RDBMS: UTF8 and UTF16 character set functionallity, and in order
-to do this it sets and unsets the related environment variables
-NLS_NCHAR and NLS_LANG.
-
-If one is not careful this changes the values set in the oracle
-table - and in the worst case stays active until the next major
-system reset. It can also be a very hard error to track down
-since it happens in a place where one normally never looks.
-
-Furthermore, it is very possibly that some or all of the UTF tests
-fails, since if one have a variable like NLS_LANG in his process
-table, then even though 'mms test' sets it in the wrong table
-it is not invoked as it is overruled by the process logical...
-
-The way to ensure that no logicals are set in the oracle table and
-that the UTF tests get the best environment to test in, and that
-DBI correctly translates the SYS$SCRATCH logical, use the
-logical
-
- PERL_ENV_TABLES
-
-to ensure that PERL's behavior is to leave the oracle table alone and
-use the process table instead:
-
- $ DEFINE PERL_ENV_TABLES LNM$PROCESS, LNM$JOB
-
-This tells PERL to use the LNM$PROCESS table as the default place to
-set and unset variables so that only the perl users environment
-is affected when installing DBD::Oracle, and ensures that the
-LNM$JOB table is read when SYS$SCRATCH is to be translated.
-
-PERL_ENV_TABLES is well documented in the PERLVMS man page.
-
-Oracle8 releases are not affected, as they don't have the
-oracle table implementation, and no UTF support.
-
-Oracle 9.0 is uncertain, since testing has not been possible yet,
-but the remedy will not hurt :)
-
-=cut
+=head1 README.vms for DBI and DBD::Oracle
+
+Date: Wed, 15 Sep 2004 11:44:09 +0300
+From: Jakob Snoer <jakob.snoer@dk.ibm.com>
+
+This is related to Oracle RDBMS 9.2 and later, since Oracle
+made fundamental changes to oracle installation requirements
+and factual installation with this release.
+
+Oracle's goal was to make VMS installation be more like on
+*nix and Windows, with an all new Oracle Home structure too,
+requiring an ODS-5 disk to install Oracle Home on instead of
+the good old ODS-2.
+
+Another major change is the introduction of an Oracle generated
+logical name table for oracle logical names like ORA_ROOT and all
+its derivatives like ORA_PROGINT etc. And that this logical name
+table is inserted in LNM$FILE_DEV in LNM$PROCESS_DIRECTOR
Y.
+
+(LNM$PROCESS_DIRECT
ORY)
+
+ "LNM$FILE_DEV" = "SERVER_810111112"
+ = "LNM$PROCESS"
+ = "LNM$JOB"
+ = "LNM$GROUP"
+ = "LNM$SYSTEM"
+ = "DECW$LOGICAL_NAMES"
+
+This ensures that any process that needs to have access to
+oracle gets the environment by just adding one logical name table
+to a central process specific mechanism.
+
+But as it is inserted at the very top of LNM$FILE_DEV it also
+represents a source of misfortune - especially if a user with
+enough privilege to update the oracle table does so (presumably
+unintentionally), as an examble by changing NLS_LANG.
+
+PERL has the abillity to define, redefine and undefine (deassign)
+logical names, but if not told otherwise by the user does it
+in the first table in above list, and not as one would normally
+expect in the process table.
+
+Installing DBI and DBD::Oracle has influence upon this since in
+both cases a few enviroment variables are read or set in the
+test phase.
+For DBI it is the logical SYS$SCRATCH, which is a JOB logical.
+For DBD-Oracle it is when testing a new feature in the Oracle
+RDBMS: UTF8 and UTF16 character set functionallity, and in order
+to do this it sets and unsets the related environment variables
+NLS_NCHAR and NLS_LANG.
+
+If one is not careful this changes the values set in the oracle
+table - and in the worst case stays active until the next major
+system reset. It can also be a very hard error to track down
+since it happens in a place where one normally never looks.
+
+Furthermore, it is very possibly that some or all of the UTF tests
+fails, since if one have a variable like NLS_LANG in his process
+table, then even though 'mms test' sets it in the wrong table
+it is not invoked as it is overruled by the process logical...
+
+The way to ensure that no logicals are set in the oracle table and
+that the UTF tests get the best environment to test in, and that
+DBI correctly translates the SYS$SCRATCH logical, use the
+logical
+
+ PERL_ENV_TABLES
+
+to ensure that PERL's behavior is to leave the oracle table alone and
+use the process table instead:
+
+ $ DEFINE PERL_ENV_TABLES LNM$PROCESS, LNM$JOB
+
+This tells PERL to use the LNM$PROCESS table as the default place to
+set and unset variables so that only the perl users environment
+is affected when installing DBD::Oracle, and ensures that the
+LNM$JOB table is read when SYS$SCRATCH is to be translated.
+
+PERL_ENV_TABLES is well documented in the PERLVMS man page.
+
+Oracle8 releases are not affected, as they don't have the
+oracle table implementation, and no UTF support.
+
+Oracle 9.0 is uncertain, since testing has not been possible yet,
+but the remedy will not hurt :)
+
+=cut
|