or was it 8.1.01.001.0001 or 8.1.01.001.0001.00001 LOL !!! too early for friday humor...
On Thu, Jul 10, 2014 at 3:03 PM, patrick zandi <remedy...@gmail.com> wrote: > got two tricks I learned recently to try... apparently coding and the Q&A > might not be the same these days... > #1 > ar.conf > modify the db server name to the following HOSTNAME,PORT (Yes that > is COMMA PORT) because of the underlying JAVA doing the connection. > > (Don't ask how I did that) > > #2 SLM issues in the oracle RAC // the actual configurations Remedy built > need to be modified cause the use the Rhyme Value:value:value and the > oracle rac is looking for > value:value\value (Yes it is Value Colon value Slash value ) > > Weird issues.. I found in 8.1.01 Windows based ARS / ITSM > > > > On Thu, Jul 10, 2014 at 1:14 PM, Joe D'Souza <jdso...@shyle.net> wrote: > >> ** >> >> @William, >> >> I usually (and I did this time too) edit my tnsnames.ora file by hand >> instead of using the Net Manager or whatever that utility is. So we can >> rule out the strange invisible character theory I think. >> >> >> >> @Patrick, >> >> I can ping the IP as well as tnsping the server with no problems. I’m not >> using the hostname but the IP instead, so an entry in the host files is not >> needed. I’m having our DBA look into this issue as well and they have not >> yet spotted anything out of the ordinary. Not yet anyways. >> >> >> >> @Fredrick, >> >> The only difference between others who can connect using the oracle user >> and password (its not a domain or NT account), is that they use corporate >> hardware so logon to the domain – I use my personal laptop, so I VPN into >> their network. I’ve been told that should not make a difference because >> they do not use any special restrictions that restrict access to only >> corporate users. >> >> >> >> As an alternate, I will try to use the Squirrel client that I have never >> used before in the hope I could at least get that working. I have noticed >> others using it here and it has a Toad like interface. I’m going to try my >> luck with that and if that works I’ll scratch off my oracle client and >> rebuild it just in case something has jinxed my SQL*Plus client. Having >> used SQL*Plus only in the past, I am more comfortable with it but with this >> problem I’m willing to go with whatever that works. I’ll let you’ll know if >> Squirrel solves the connection problems.. >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *William Rentfrow >> *Sent:* Wednesday, July 09, 2014 4:58 PM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Slightly OT: Connecting SQL*Plus client to an Oracle >> Database.. >> >> >> >> I've seen two different times where the tnsnames.ora file had some type >> of invisible control character in it and the file would not work. >> >> >> >> We'd re-type it and try again and it worked - even though the files would >> be identical to visual inspection and were checked by multiple people. >> >> >> >> If you're on Unix you might want to run dos2unix on the file. >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Grooms, Frederick W >> *Sent:* Wednesday, July 09, 2014 3:51 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Slightly OT: Connecting SQL*Plus client to an Oracle >> Database.. >> >> >> >> ** >> >> Ok … Since you can connect to other databases listed in the TNSNAMES.ORA >> file that should rule that out >> >> >> >> Since you have SQLNET.AUTHENTICATION_SERVICES= (NTS) I wonder if there >> is a permissions issue with the user and password you were given. >> >> >> >> NTS uses Windows native authentication to allow access to a database. If >> you are specifying a user and password yourself I usually prefer to set >> this to NONE or comment out that line in the sqlnet.ora file. >> >> >> >> Fred >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Joe D'Souza >> *Sent:* Wednesday, July 09, 2014 3:25 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Slightly OT: Connecting SQL*Plus client to an Oracle >> Database.. >> >> >> >> ** >> >> I can connect to other databases whose connection strings are defined in >> that tnsnames.ora file. So that rules out the client not being able to find >> the tnsnames.ora file or any permission related issue to that file. >> >> >> >> I haven’t made any changes to the sqlnet.ora file. The only two non >> commented lines in it are: >> >> >> >> SQLNET.AUTHENTICATION_SERVICES= (NTS) >> >> >> >> NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) >> >> >> >> Cheers >> >> >> >> >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *Grooms, >> Frederick W >> *Sent:* Wednesday, July 09, 2014 12:20 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Slightly OT: Connecting SQL*Plus client to an Oracle >> Database.. >> >> >> >> I can think of 2 possible reasons off the top of my head. >> >> >> >> One reason is that SQLPLUS could not find the TNSNAMES.ORA file. Do you >> have an environment variable of TNS_ADMIN? >> >> In my systems I have that environment variable pointing to the folder >> where the tnsnames.ora file is located. SQLPLUS (and the Oracle client in >> general) use this environment variable to find the tnsnames.ora >> configuration file. >> >> >> >> Another possible reason could be a default domain setting. >> >> In your Oracle Client configuration do you have an SQLNET.ORA >> configuration file that defines? >> >> names.default_domain = world >> >> >> >> In those cases the TNSNAMES entry wanted to be: >> >> CONNENTRY.WORLD = >> >> (DESCRIPTION = >> >> (ADDRESS = (PROTOCOL = TCP)(HOST = 111.111.11.111)(PORT = 1521)) >> >> (CONNECT_DATA = >> >> (SERVER = DEDICATED) >> >> (SERVICE_NAME = connentry) >> >> ) >> >> ) >> >> >> >> And then my login using SQLPLUS would be >> >> sqlplus user@CONNENTRY.WORLD >> >> >> >> Fred >> >> >> >> >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *Joe >> D'Souza >> *Sent:* Wednesday, July 09, 2014 10:44 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Slightly OT: Connecting SQL*Plus client to an Oracle >> Database.. >> >> >> >> ** >> >> We have our Remedy database on Oracle 11.2.0.3.0 - 64bit Production >> server. >> >> >> >> I am using SQL*Plus Release 10.2.0.1.0 client to connect to it but am >> unable to connect with a connection error that reads as: >> >> >> >> ORA-12154: TNS:could not resolve the connect identifier specified >> >> >> >> I have checked my tnsnames.ora file for any possible errors in the >> connection string and can’t seem to find one. This is the contents of the >> entry (I have replaced the actual IP and the service name and what not >> with fictitious names for security reasons – the port is 1521 which is the >> default port.) >> >> >> >> ## Remedy ITSM db - Devl - Used IP instead of hostname >> >> CONNENTRY = >> >> (DESCRIPTION = >> >> (ADDRESS = (PROTOCOL = TCP)(HOST = 111.111.11.111)(PORT = 1521)) >> >> (CONNECT_DATA = >> >> (SERVER = DEDICATED) >> >> (SERVICE_NAME = connentry) >> >> ) >> >> ) >> >> >> >> While connecting I use the username & password as given to me and >> connentry as the host string. >> >> >> >> What could possibly be the causes of ORA-12154 that I ought to check for? >> I suspect something wrong with my connection string in my tnsnames.ora file >> but can’t figure what it is. I checked with the DBA’s for the exact IP, >> port, service name and they say it all checks out. >> >> >> >> I was also suspecting that perhaps Oracle client 10.2.0.1.0 may not be >> compatible with Oracle Database version 11.2.0.3.0, but I do not think that >> could be the problem as Oracle clients are usually compatible with at least >> 1 version forward or backward. >> >> >> >> >> >> Any insights as to what I and my DBA’s may be missing may help.. >> >> >> >> Thanks.. >> >> >> >> Joe >> >> >> >> >> >> >> >> >> ------------------------------ >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2014.0.4716 / Virus Database: 3986/7812 - Release Date: 07/07/14 >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: >> "Where the Answers Are" and have been for 20 years_ > > > > > -- > Patrick Zandi > -- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
