tensmekl@infonode.ingr.com (Kermit Tensmeyer) (01/24/91)
I'm supposed to be the local expert on ORACLE, but here one that got by me. I'll gladly give up my crown to anybody willing to wear it. The Unix Environment variable TWO_TASK determines the "default" device driver. "F:" indicates the fast (shared memory) driver. While "T:machine:sid" indicate a default connect to a remote machine via SQL*Net using TCP/IP. This all works well with SQL*Plus SQL*Forms imp exp and sqldba. However, this kind of default action doesn't seem to effect the default connect under Pro*C. Is there some call or parameters to Pro*C Exec SQL that will use either the Environment Variables, the .sqlnet options or the Database Link's in the database without my having to recode the standard behavor in my C code. -- Kermit Tensmeyer | Intergraph Corporation UUCP: ...uunet!ingr!tensmekl | One Madison Industrial Park INTERNET: tensmekl@ingr.com | Mail Stop LR23A2 AT&T: (205)730-8127 | Huntsville, AL 35807-4201
hthoene@doitcr.doit.sub.org (Hermann Thoene) (01/29/91)
In article <1991Jan24.033628.20710@infonode.ingr.com> tensmekl@infonode.ingr.com (Kermit Tensmeyer) writes: > >The Unix Environment variable TWO_TASK determines the "default" device >driver. "F:" indicates the fast (shared memory) driver. While "T:machine:sid" >indicate a default connect to a remote machine via SQL*Net using TCP/IP. > >This all works well with SQL*Plus SQL*Forms imp exp and sqldba. However, >this kind of default action doesn't seem to effect the default connect >under Pro*C. Is there some call or parameters to Pro*C Exec SQL that will >use either the Environment Variables, the .sqlnet options or the Database Link's >in the database without my having to recode the standard behavor in my C code. > You **must** change your C code to evalute the Environment variable TWO_TASK with the getenv() call in C. It is left to the application (here to your PRO*C program) to build the connect string together. So just check up whether TWO_TASK is set and append the string to the connect string given to your program. Servus from Germany Hermann Thoene, Muenchen, Bavaria <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< hthoene@doitcr.doit.sub.org
jean@beno.CSS.GOV (Jean Anderson) (02/02/91)
In article <1991Jan24.033628.20710@infonode.ingr.com> tensmekl@infonode.ingr.com (Kermit Tensmeyer) writes: >> >>The Unix Environment variable TWO_TASK determines the "default" device >> ... >>This all works well with SQL*Plus SQL*Forms imp exp and sqldba. However, >>this kind of default action doesn't seem to effect the default connect >>under Pro*C. Is there some call or parameters to Pro*C Exec SQL that will > In <1585@doitcr.doit.sub.org> hthoene@doitcr.doit.sub.org (Hermann Thoene): >You **must** change your C code to evalute the Environment variable >TWO_TASK with the getenv() call in C. It is left to the application (here >to your PRO*C program) to build the connect string together. So just check >up whether TWO_TASK is set and append the string to the connect string >given to your program. We use TWO_TASK to connect to remote databases with PRO*C and PRO*FORTRAN applications and have never had to append the TWO_TASK information to the database connect string. Occasionally, however, some poor soul doesn't have his/her environment set up properly. To head this confusion off at the pass, we include something like the following in our dbopen routine before we even try to do the connect: uidptr=strchr(uid, '@'); /* Is sqlnet info explicitely in uid? */ if(uidptr == NULL) /* sqlnet info not in uid */ { p=getenv("TWO_TASK"); /* Is TWO_TASK set? */ if(p == NULL) /* TWO_TASK not set */ { p=getenv("ORACLE_SID"); /* Is ORACLE_SID set? */ if(p == NULL) /* ORACLE_SID not set */ { fprintf(stderr,"Database environment not set up--see your DBA\n"); return(BADDATA); } } } I periodically get email: "Uh, what do I need to do to set my environment up for the database?" - Jean Anderson DBA, SAIC Geophysics Division jean@seismo.css.gov -or- jean@esosun.css.gov (619)458-2727 +++++++++++++++++++++++++++++++++++++++++++++++++ ++ Any opinions are mine, not my employer's. ++ +++++++++++++++++++++++++++++++++++++++++++++++++
lwk@caen.engin.umich.edu (Woody Kellum) (02/11/91)
In article <49392@seismo.CSS.GOV> jean@beno.CSS.GOV (Jean Anderson) writes: > >We use TWO_TASK to connect to remote databases with PRO*C and PRO*FORTRAN >applications and have never had to append the TWO_TASK information to the >database connect string. Occasionally, however, some poor soul doesn't have >his/her environment set up properly. To head this confusion off at the pass, >we include something like the following in our dbopen routine before we >even try to do the connect: > > uidptr=strchr(uid, '@'); /* Is sqlnet info explicitely in uid? */ > if(uidptr == NULL) /* sqlnet info not in uid */ > { > p=getenv("TWO_TASK"); /* Is TWO_TASK set? */ > if(p == NULL) /* TWO_TASK not set */ > { > p=getenv("ORACLE_SID"); /* Is ORACLE_SID set? */ > if(p == NULL) /* ORACLE_SID not set */ > { > fprintf(stderr,"Database environment not set up--see your DBA\n"); > return(BADDATA); > } > } > } > > >I periodically get email: "Uh, what do I need to do to set my environment >up for the database?" > > - Jean Anderson I have a shell file that I have users source before they try to connect which sets up their environment for them. All they give is the alias name of the DB they want to connect to. The first thing I ask when they call with problems is: "Did you source the oracle file first?" -- I want a GOOD reason with some moral backbone why Americans are dying in the Mid East. Woody Kellum Internet: lwk@caen.engin.umich.edu