RE: Database Links standards
Title: Database Links standards
Jeff,
Looks
ok, except that I don't think you need step b) - the PUBLIC SYNONYM for the
remote table.
I
always create a private synonym within my DBA account (which happens to own the
tables in the local database) and then create the VIEW and a PUBLIC SYNONYM on
the view to hide everything from the user. The view will say
:
select
* from table@dblink.
The
developers then get access to the view only - never to the base db-linked
tables.
Your
approaches works for me, though. Tell the developers to use it as
delivered and to like it! :)
hope
this helps.
Tom Mercadante Oracle Certified Professional
-Original Message-From: Thomas Jeff
[mailto:[EMAIL PROTECTED]]Sent: Friday, July 06, 2001 4:51
PMTo: Multiple recipients of list ORACLE-LSubject:
Database Links standards
We came up with the below standards with respect to
database links (heavily used in our
environment). The result has been a billion complaints by
our developers, stating that the standards are unnecessarily
complex. I'm curious as to what others might
think, if they *are* indeed too complex. Also what
kind of naming/adminstrative standards that other shops employ.
1. To access remote data across a DB LINK, the
standard implementation consists of four
pieces:
a) A private database link owned by the schema owner of the
table objects being accessed. The
CONNECT TO and IDENTIFIED BY clauses are
required - Naming
Standard: {remote schema}_{database name}
b) A standard PUBLIC SYNONYM created for the remote table
being accessed across the link.
- Naming Standard: {remote
schema}_{remote table}. The purpose of this synonym is both to allow portability and also
to provide documentation of
the remote connection.
c) A VIEW created as a SELECT * from the PUBLIC SYNONYM above
(1.b). - Naming
Standard: {remote table}_VW
d) A PUBLIC SYNONYM on the VIEW above(1.c.) - Naming Standard: {remote table}
Thanks, Jeff T [EMAIL PROTECTED]
RE: Database Links standards
Title: Database Links standards
this
is fine.
your
problem may be in marketing the technology, not the technology itself.
-Original Message-From: Thomas Jeff
[mailto:[EMAIL PROTECTED]]Sent: Friday, July 06, 2001 4:51
PMTo: Multiple recipients of list ORACLE-LSubject:
Database Links standards
We came up with the below standards with respect to
database links (heavily used in our
environment). The result has been a billion complaints by
our developers, stating that the standards are unnecessarily
complex. I'm curious as to what others might
think, if they *are* indeed too complex. Also what
kind of naming/adminstrative standards that other shops employ.
1. To access remote data across a DB LINK, the
standard implementation consists of four
pieces:
a) A private database link owned by the schema owner of the
table objects being accessed. The
CONNECT TO and IDENTIFIED BY clauses are
required - Naming
Standard: {remote schema}_{database name}
b) A standard PUBLIC SYNONYM created for the remote table
being accessed across the link.
- Naming Standard: {remote
schema}_{remote table}. The purpose of this synonym is both to allow portability and also
to provide documentation of
the remote connection.
c) A VIEW created as a SELECT * from the PUBLIC SYNONYM above
(1.b). - Naming
Standard: {remote table}_VW
d) A PUBLIC SYNONYM on the VIEW above(1.c.) - Naming Standard: {remote table}
Thanks, Jeff T [EMAIL PROTECTED]
Re: Database Links standards
Looks good to me, except for step b.
You don't really need that.
I've used the same setup several
times successfully.
Jared
On Friday 06 July 2001 13:51, Thomas Jeff wrote:
We came up with the below standards with respect to database links
(heavily
used in our environment). The result has been a billion complaints by
our developers, stating that the standards are unnecessarily complex. I'm
curious as to what others might think, if they *are* indeed too complex.
Also what kind of naming/adminstrative standards that other shops employ.
1. To access remote data across a DB LINK, the
standard implementation consists of four pieces:
a) A private database link owned by the schema owner of the table
objects being accessed. The CONNECT TO and IDENTIFIED BY clauses are
required
- Naming Standard: {remote schema}_{database name}
b) A standard PUBLIC SYNONYM created for the remote table being
accessed across the link.
- Naming Standard: {remote schema}_{remote table}. The purpose of this
synonym is both to allow portability and also to provide documentation
of the remote connection.
c) A VIEW created as a SELECT * from the PUBLIC SYNONYM above (1.b).
- Naming Standard: {remote table}_VW
d) A PUBLIC SYNONYM on the VIEW above(1.c.)
- Naming Standard: {remote table}
Thanks,
Jeff T
[EMAIL PROTECTED]
Content-Type: text/html; charset=iso-8859-1; name=Attachment: 1
Content-Transfer-Encoding: 7bit
Content-Description:
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jared Still
INET: [EMAIL PROTECTED]
Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051
San Diego, California-- Public Internet access / Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
RE: Database Links
Can I give a suggestion , how about create a unique user which will have all the link db , so much so that we will know where is the link come from , and it seen easily to manage ? Will it be a solution to this ? -Original Message- Sent: Thursday, May 31, 2001 2:46 PM To: Multiple recipients of list ORACLE-L Tracy, Allowing developers to muck around in your production system is not generally a good idea. If you create db links for them, that's what they will be doing. In addition, have you ever managed an environment like that? I have and it's not pretty. How will you administer the privileges? Will it be a public database link ( dangerous ) or lots of private database links (messy )? Will the connection be to their own account on the production system ( that you must create ) or an account that has all the needed privs? Managing this is something of a headache. And when your developers do a cartesian join on your production database, you will be scrambling to determine which session is causing it, and determining if you can safely kill it. etc, etc, etc. :) Jared On Wednesday 30 May 2001 16:09, Tracy Rahmlow wrote: We have several large look-up tables that we use in development as well as in production environments. The data is the same in both environments. I am looking for some comments regarding whether or not we store duplicate data in each environment or should we allow the development users to access the table in production through a database link. Below, I have listed some issues with both of these processes and am looking for further input. Thanks Duplicate table in production and development (either through export/import or snapshots): Cons additional storage is need process needed to keep tables in sync Pros reduced network traffic Access table in production through a database link in development: Cons additional network traffic possibility of poorly tuned adhoc sql executing in a production environment Pros only one copy of table do not need an ongoing process to keep the tables in sync -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Raymond Lee Meng Hong INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Database Links
Tracy, I have a similar deal going on here. If you are on version 8.1.x and the lookup tables are large, you can use Materialized Views, and since they are lookup tables that shouldn't change much, you should only have to refresh them every once in a while. If they are really small tables, however, you can just use database links. What I do is create a view across a database link on top of the lookup tables. I then create a synonym on the view that is the same as the lookup tables' name. The users, then, have no idea the tables don't exist locally. Jim Jim Hawkins Lead SAPR/3 Oracle DBA MEMC Electronic Materials, Inc. St. Louis, MO (636) 474-7832 [EMAIL PROTECTED] (work) [EMAIL PROTECTED] (personal) -Original Message- Rahmlow Sent: Wednesday, May 30, 2001 6:10 PM To: Multiple recipients of list ORACLE-L We have several large look-up tables that we use in development as well as in production environments. The data is the same in both environments. I am looking for some comments regarding whether or not we store duplicate data in each environment or should we allow the development users to access the table in production through a database link. Below, I have listed some issues with both of these processes and am looking for further input. Thanks Duplicate table in production and development (either through export/import or snapshots): Cons additional storage is need process needed to keep tables in sync Pros reduced network traffic Access table in production through a database link in development: Cons additional network traffic possibility of poorly tuned adhoc sql executing in a production environment Pros only one copy of table do not need an ongoing process to keep the tables in sync -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Tracy Rahmlow INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hawkins Family INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Database Links
We have several large look-up tables that we use in development as well as in production environments. The data is the same Developers shouldn't work against production tables. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Greg Moore INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Database Links
Tracy, Allowing developers to muck around in your production system is not generally a good idea. If you create db links for them, that's what they will be doing. In addition, have you ever managed an environment like that? I have and it's not pretty. How will you administer the privileges? Will it be a public database link ( dangerous ) or lots of private database links (messy )? Will the connection be to their own account on the production system ( that you must create ) or an account that has all the needed privs? Managing this is something of a headache. And when your developers do a cartesian join on your production database, you will be scrambling to determine which session is causing it, and determining if you can safely kill it. etc, etc, etc. :) Jared On Wednesday 30 May 2001 16:09, Tracy Rahmlow wrote: We have several large look-up tables that we use in development as well as in production environments. The data is the same in both environments. I am looking for some comments regarding whether or not we store duplicate data in each environment or should we allow the development users to access the table in production through a database link. Below, I have listed some issues with both of these processes and am looking for further input. Thanks Duplicate table in production and development (either through export/import or snapshots): Cons additional storage is need process needed to keep tables in sync Pros reduced network traffic Access table in production through a database link in development: Cons additional network traffic possibility of poorly tuned adhoc sql executing in a production environment Pros only one copy of table do not need an ongoing process to keep the tables in sync -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: database links
Hi, Millie, Try this location ftp://oracle-ftp.oracle.com/server/ HTH Vadim Gorbounov Oracle DBA -Original Message- Sent: Wednesday, April 11, 2001 10:26 AM To: Multiple recipients of list ORACLE-L I have set the global_names parameter to false on my mainframe database ORS1 and recycled the data base. When I do a select * from global_name, it show the name of ORS1. When I do the same on the unix database dw1, it show the name of DW1.WORLD. When I do select * from dba_db_link on ORS1, it show other host as dw1.world. How can I change my global_name to be ors1.world? What should the SERVICE_NAME parameter be? We don't use this parameter, I tried serveral different names, but it didn't seem to make any difference. Thanks. Millie -Original Message- Sent: Saturday, April 07, 2001 2:00 AM To: Multiple recipients of list ORACLE-L Millie, Check both instances and verify if global_names parameter is switched on. What is the name of your db link? select * from global_name; Is it the same as global_name? I have a problems creating database links when I have global_names parameter set to TRUE. I normally switch global_names=false unless the application uses global_names. I create my database link using the connect description from my tnsnames.ora file for that instance. It normally works. eg. create database link test connect to jdatest identified by jdatest using '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = odbms)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = test) ) )' ; This normally works for me. DB links are very fussy when it comes to global names. Also the name that is given to your db link when global names are used. HTH Suhen Suhen We are setting up a test Oracle 8i (8.1.7 with OSDI) on our mainframe (os/390 v2.8), we can connect to the database instance (ORS1) from windows NT client, but when we try to connect to it using database links set up from our unix platform, we get ORA-12154 TNS: Could not resolve service name When we try to link from ors1 I get: ORA-02019 Connection Description For Remote Database Not Found. We created a tar with Oracle and waiting to hear from them. Just wondering if anyone on the list has the same problem? Millie Chan Rutgers, The State University of New Jersey Administrative Computing Services 65 Davidson Road Piscataway, NJ 08855 Tel: (732)445-5433 EMAIL: [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Chan, Millie INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Suhen Pather INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Chan, Millie INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Vadim Gorbounov INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the
RE: database links - had problem, hlp me urgent pls
hi Suhen, i too before tried to create a db like millie, i failed now i applied as u suggested and i succeed also in one case. What happened u know, i have 2 machines development machine(V731) and in my PC i have my own database(V815). First time i created a db link from the development machine to my server. This case i suceeded. But again i tried to create another DB link from my server to development machine. i time i got 'Uable to resolve TNS names' like that for the first time and 2nd time also got the error similar to the first one, 3rd time i got the error as like below "ORA-00602: internal programming exception %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=, PC=, PS=". then i stoped to create the db link. Now the problem is, am not able to connect to my development m/c through any tool like sql, d2k. All cases i got the following error. What is the proble what i did mistake in that, Could any one clear me please, it's very urgent.. thanks in advance.. SQL*Plus: Release 8.0.6.0.0 - Production on Sun Apr 8 13:35:19 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved. ERROR: ORA-00602: internal programming exception %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=, PC=, PS= ERROR: ORA-00602: internal programming exception %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=, PC=, PS= Error accessing package DBMS_APPLICATION_INFO ERROR: ORA-00602: internal programming exception %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=, PC=, PS= Connected to: Oracle7 Server Release 7.3.4.3.0 - Production With the distributed option PL/SQL Release 2.3.4.3.0 - Production SQL Regards, Nirmal. -Original Message- From: Suhen Pather [SMTP:[EMAIL PROTECTED]] Sent: Saturday, April 07, 2001 9:00 AM To: Multiple recipients of list ORACLE-L Subject: RE: database links Millie, Check both instances and verify if global_names parameter is switched on. What is the name of your db link? select * from global_name; Is it the same as global_name? I have a problems creating database links when I have global_names parameter set to TRUE. I normally switch global_names=false unless the application uses global_names. I create my database link using the connect description from my tnsnames.ora file for that instance. It normally works. eg. create database link test connect to jdatest identified by jdatest using '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = odbms)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = test) ) )' ; This normally works for me. DB links are very fussy when it comes to global names. Also the name that is given to your db link when global names are used. HTH Suhen Suhen We are setting up a test Oracle 8i (8.1.7 with OSDI) on our mainframe (os/390 v2.8), we can connect to the database instance (ORS1) from windows NT client, but when we try to connect to it using database links set up from our unix platform, we get ORA-12154 TNS: Could not resolve service name When we try to link from ors1 I get: ORA-02019 Connection Description For Remote Database Not Found. We created a tar with Oracle and waiting to hear from them. Just wondering if anyone on the list has the same problem? Millie Chan Rutgers, The State University of New Jersey Administrative Computing Services 65 Davidson Road Piscataway, NJ 08855 Tel: (732)445-5433 EMAIL: [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Chan, Millie INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Suhen Pather INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of
RE: database links
hi millie, you must verify that the host name is resolved in the unix platform(DNS), otherwise put the physical adress in the description of the host. Best Regards, Nabila Mekkaoui DBA -Message d'origine- De : Chan, Millie [mailto:[EMAIL PROTECTED]] Envoy : vendredi 6 avril 2001 19:51 : Multiple recipients of list ORACLE-L Objet : database links We are setting up a test Oracle 8i (8.1.7 with OSDI) on our mainframe (os/390 v2.8), we can connect to the database instance (ORS1) from windows NT client, but when we try to connect to it using database links set up from our unix platform, we get ORA-12154 TNS: Could not resolve service name When we try to link from ors1 I get: ORA-02019 Connection Description For Remote Database Not Found. We created a tar with Oracle and waiting to hear from them. Just wondering if anyone on the list has the same problem? Millie Chan Rutgers, The State University of New Jersey Administrative Computing Services 65 Davidson Road Piscataway, NJ 08855 Tel: (732)445-5433 EMAIL: [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Chan, Millie INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INF/MEKKAOUI INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: database links
Millie, Check both instances and verify if global_names parameter is switched on. What is the name of your db link? select * from global_name; Is it the same as global_name? I have a problems creating database links when I have global_names parameter set to TRUE. I normally switch global_names=false unless the application uses global_names. I create my database link using the connect description from my tnsnames.ora file for that instance. It normally works. eg. create database link test connect to jdatest identified by jdatest using '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = odbms)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = test) ) )' ; This normally works for me. DB links are very fussy when it comes to global names. Also the name that is given to your db link when global names are used. HTH Suhen Suhen We are setting up a test Oracle 8i (8.1.7 with OSDI) on our mainframe (os/390 v2.8), we can connect to the database instance (ORS1) from windows NT client, but when we try to connect to it using database links set up from our unix platform, we get ORA-12154 TNS: Could not resolve service name When we try to link from ors1 I get: ORA-02019 Connection Description For Remote Database Not Found. We created a tar with Oracle and waiting to hear from them. Just wondering if anyone on the list has the same problem? Millie Chan Rutgers, The State University of New Jersey Administrative Computing Services 65 Davidson Road Piscataway, NJ 08855 Tel: (732)445-5433 EMAIL: [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Chan, Millie INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Suhen Pather INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
