Join the world’s largest interactive community dedicated to Oracle technologies.

No I did not mean that. I was pointing out that we don't know where connecting without a connection string is going to get you. And we don't know that the hr user doesn't have the create session privilege. Making the request questionable.

Andrew Sayer wrote:

 

Gbenga Ajakaye wrote:

 

Then, try to connect using below command and see if work. if it fails, then you might not have the right password.

 

Can you and try again.

grant create session to HR:

sqlplus HR/HR@PDBORCL;

 

When OP connects to the DB without a connection string, where does OP connect to?

 

Additionally, you get a different error when you try to connect to a user without the create session privilege - but you must get the password correct first:

ANDY@orcl>create user hra identified by hra;

User created.

ANDY@orcl>conn hra/HRA
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
ANDY@orcl>conn hra/hra
ERROR:
ORA-01045: user HRA lacks CREATE SESSION privilege; logon denied

To whatever SID is set before connecting to sqlplus. So, if orcle was set

sqlplus /nolog

conn hra/HRA will try to connect to orcl.

I do see you point - as illustrated by the sample - that a wrong password has nothing to do with having create session priv.

3373013 wrote:

 

Please let me know what needs to be done to run SQL LOADER.

Go back to where you did something to your tnsnames.ora file and recover it. It used to have an entry for pdborcl and now it doesn't.

tnsping pdborcl

From the command line should return without an error when you have done this.

[oracle@vbgeneric Desktop]$ sqlplus sys/oracle as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Mon Jan 23 16:50:28 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> alter user hr identified by hr account unlock;

User altered.

SQL> connect hr/hr

Connected.

SQL> show user

USER is "HR"

SQL>

So what happened to your tnsnames files?

https://community.oracle.com/servlet/JiveServlet/showImage/2-14197233-294972/pastedImage_1.png

Shows that it used to point somewhere.

3373013 wrote:

 

As I hinted to Gbenga, without a connection string you will be pointing to the default database most likely the CDB of your multitenant db. This is not the same DB that you would be doing your normal work on (like loading tables).

I don't understand why you continue to ignore my question about your tnsnames file, what happened to it?

It HAD an entry for pdborcl before, which would have allowed @pdborcl to identify the appropriate DB to connect to.

So find that tnsnames file and find out what changed in the last few minutes.

It should be in the

c:\app\client\khushi\product\12.1.0\client_1\network\admin\

directory.

Open it up, and see what's happened to it.

Is that the only tnsnames.ora file? It allows me to tnsping pdborcl and use @pdborcl as a connection string just fine.

I'll note that the file contains

# tnsnames.ora Network Configuration File: C:\app\sunita\product\12.1.0\dbhome_1\network\admin\tnsnames.ora

But your tnsping used the sqlnet.ora in

c:\app\client\khushi\product\12.1.0\client_1\network\admin\

So what's the difference? Is this all the same machine? is this the client machine? It is the client's tnsnames.ora file that gets searched for when the client attempts to connect to the DB.