Support Services Corporate Home EarthVision Events
 
FAQs


OpenWorks Data Import FAQs

The following is a list of frequently asked questions about the EarthVision program, evgetdata, that imports data from a Landmark OpenWorks project.

1. Q: What kinds of data can I import?

2. Q: What operating systems are supported?

3. Q: What OpenWorks version does the suite of import programs work with?

4. Q: What version of the Oracle server is required?

5. Q: Our Oracle server runs on a Solaris machine but we want to run the import programs on workstations from SGI. Will this work?

6. Q: We will be running the import programs on different workstations from where the Oracle server is running. What do we need on the client workstations?

7. Q: Do we have to load SQL*Net on every client workstation?

8. Q: Where can I get SQL*Net from?

9. Q: I don't know which user accounts are set up to access OpenWorks. How can I test the import programs?

10. Q: How do I test an account to see if it can access Oracle?

11. Q: What environment variables do users need to have defined to run the import programs?

12. Q: How do Unix accounts get the privileges required to access data in OpenWorks?

13. Q: How can I import well data without using the graphical interface program (evgetdata)?

14. Q: Running on an SGI workstation I get:
   Fatal Error: Cannot Successfully Map soname 'libnsl.so' under any of the filenames /usr/lib:...".

15. Q: SQL*Plus will not run on the workstation that the import programs will be run on. What should I do?

16. Q: I get error ORA-01019. What does this mean?

17. Q: I get the message: Error while trying to retrieve text for error ORA-12203. What's wrong?

18. Q: I get ORA-12203: TNS:unable to connect to destination. Why?

19. Q: I get ORA-12154: TNS:could not resolve service name.

20. Q: I get ORA-02019: connection description for remote database not found. What now?

1. What kinds of data can I import?

Log curves, well paths, top picks, fault picks, completions, and map data (point sets, grids, vertical faults, and non-vertical faults) can be imported from OpenWorks.

2. What operating systems are supported?

Currently SGI IRIX 6.2 and higher and Solaris 2.5.1 and higher.

3. What OpenWorks version does the suite of import programs work with?

You must have version 4.0 or 5.0. Earlier versions came with a version of Oracle that is incompatible with the import programs.

4. What version of the Oracle server is required?

7.2.3 or higher. The following commands will give the server version as well as some other info:
     $ORACLE_HOME/bin/sqlplus lmsys/lmsys[@connect-string]
     SQL> quit

The connect-string in the above command is also called the "database alias." In the case of OpenWorks, it is the value of OWSYSSID and ORACLE_SID.

5. Our Oracle server runs on a Solaris machine but we want to run the import programs on workstations from SGI. Will this work?

Yes. We currently have clients doing this successfully. Only the Oracle SQL*Net program must also be installed on the SGI.

6. We will be running the import programs on different workstations from where the Oracle server is running. What do we need on the client workstations?

SQL*Net version 2 must be available on all of the client workstations for them to connect to the server.

7. Do we have to load SQL*Net on every client workstation?

Only if you do NOT have NFS running. If NFS is running, then each workstation just has to mount the disk which has SQL*Net on it.

8. Where can I get SQL*Net from?

If you are an OpenWorks user, just copy it off of the OpenWorks distribution CD. The CD comes with versions for IRIX and Solaris. Landmark, however, does not provide a way to copy just SQL*Net (rather than all of Oracle off of the CD). Dynamic Graphics, therefore, now provides the script copySqlnetFromOWcd, which will do that.

9. I don't know which user accounts are set up to access OpenWorks. How can I test the import programs?

You can get the valid accounts by asking Oracle what they are. Enter the following:
      $ORACLE_HOME/bin/sqlplus owsys/owsys[@connect-string]
      SQL> select project_name,user_id from ow_sys_prj_user;
      SQL> quit

The output indicates the user_id's that are allowed to access each project.

10. How do I test an account to see if it can access Oracle?

This is most easily done using SQL*Plus. Log into a Unix shell as a valid OpenWorks user. Then try the following:
     $ORACLE_HOME/bin/sqlplus /[@connect-string]

If you get in, then everything is fine. If you get:
     ERROR: ORA-01017: invalid username/password; login denied

this message may mean that Oracle has not been configured for access over the network (if the Oracle server is on a different workstation). If so, then shut Oracle down and edit the file init.ora and add:

     remote_os_authent=true

anywhere in the file. Then start Oracle back up.

11. What environment variables do users need to have defined to run the import programs?

Add the following to each user's .cshrc file:
     setenv ORACLE_HOME <location of Oracle>
     setenv OWHOME <location of OpenWorks>

12. How do Unix accounts get the privileges required to access data in OpenWorks?

OpenWorks must be used to grant these privileges. They are granted on a project by project bases. For example to give the account "DGI" access to projects in OpenWorks you would do the following:
     a) Run Landmark program "orauser" to create an account in Oracle for the Unix account "DGI".
     b) Start OpenWorks and use it to grant access to each project that you want the "DGI" account to be allowed to access.

13. How can I import well data without using the graphical interface program (evgetdata)?

The file $DGIHOME/ev5/support/oracle/applicationExamples gives examples of using the underlying program (ev_getdata) directly. Type ev_getdata -h or man ev_getdata to list all of the options.

14. Running on an SGI workstation I get: Fatal Error: Cannot Successfully Map soname 'libnsl.so' under any of the filenames /usr/lib:...".

This is an SGI system library. You need to load it from an SGI distribution CD. It comes in different subsystems depending on the OS version as follows:
IRIX 6.2:
     eoe.sw.svr4net
IRIX 6.3:
     eoe.sw.irix_lib
IRIX 6.5:
     eoe.sw.base

15. SQL*Plus will not run on the workstation that the import programs will be run on. What should I do?

SQL*Plus is only used when running the installation script so just login into the workstation that has the Oracle server (and thus SQL*Plus) when doing the installation. All of the installation scripts are operating system independent. You can run them anywhere. Just copy them to a platform that SQL*Plus runs on. If you want to run SQL*Plus on an IRIX workstation on which it has not been run before, you will normally have to do the following:
     a) log in as root
     b) cd /usr/lib
     c) if libsocket.so exists:
       mv libsocket.so libsocket.so.O
     d) ln -s libc.so.1 libsocket.so

16. I get error ORA-01019. What does this mean?

This means that the client (ev_getdata) cannot communicate with the Oracle server. It is not caused by the usual types of communication problems though. A number of things can cause it. The most common cause is a version of SQL*Net that is incompatible with the import programs.

17. I get the message: Error while trying to retrieve text for error ORA-12203. What's wrong?

SQL*Net cannot access its message files; therefore, it cannot print out the error message. This most likely means that ORACLE_HOME is misdefined meaning the message files cannot be found. Make sure that ORACLE_HOME is correct. Also all of the .msg and .msb files must have read permission and the directories containing them should have execute permission.

18. I get ORA-12203: TNS:unable to connect to destination. Why?

There can be a variety of reasons. One possibility is that the Oracle server is down.

19. I get ORA-12154: TNS:could not resolve service name.

The database name that you have chosen is incorrect or not available or SQL*Net does not know about it. Make sure that you have entered a valid database name in the import program interface.

20. I get ORA-02019: connection description for remote database not found. What now?

This means that Oracle has not been configured to allow database links. Versions of ev_getdata from March 5, 1998 and later do not require database links. In this case, you are running an older version of ev_getdata. Install the 5.0 version of ev_getdata.

 

 
[Home] [Corporate] [Events & News]
[EarthVision] [Support] [Services] [Contact Us]


© 1999-2007 Dynamic Graphics, Inc. All Rights Reserved. Legal Notices.
See Legal Notices for appropriate copyright trademark legend.
Feedback: webmaster@dgi.com

Last updated: March 22, 2007