Oracle Forms

but when i run
create user c##sms01 identified by sms01; is ok how can i create user without c##  in 12c

Without c## means you're looking to create a LOCAL user?

You have to be inside the pdb. It should follow like this: Change pdb to your pdbdatabase

ALTER SESSION SET CONTAINER = pdb;
CREATE USER sms01 IDENTIFIED BY sms01 CONTAINER=CURRENT; or 
CREATE USER sms01 IDENTIFIED BY sms01; 

Set the necessary parameter, and yu can do what you like:

orclz> create user c##garb identified by 1;
create user c##garb identified by 1
            *
ERROR at line 1:
ORA-65094: invalid local user or role name
orclz> alter session set "_oracle_script"=true;
Session altered.
orclz> create user c##garb identified by 1;
User created.
orclz>

JamesMichael wrote:
i run this query creating use
CREATE USER sms01 IDENTIFIED BY sms01;
i got 
Error report:
SQL Error: ORA-65096: invalid common user or role name
but when i run 
create user c##sms01 identified by sms01; is ok how can i create user without c## in 12c

See my extensive replies in this thread and the other threads referenced there.

creating users in oracle 12c

Many things, even basic things like creating users, are done differently in 12c. In 12c there are common users and local users. You need to know and understand the difference. My 'guess' is that you are trying to create a user (e.g. SOMEUSER) and getting an exception because you are trying to create that user in the root CDB and you can ONLY create common users in the root. And SOMEUSER can not possibly be a common user because common users are defined differently.
You also need to read and understand chapters 17 and 18 of the Concepts doc about the new multitenant architecture of 12c.
http://docs.oracle.com/cd/E16655_01/server.121/e17633/part_consol.htm#CHDGDBHJ

JohnWatson2 wrote:
Set the necessary parameter, and yu can do what you like:

orclz> create user c##garb identified by 1; create user c##garb identified by 1  * ERROR at line 1: ORA-65094: invalid local user or role name     orclz> alter session set "_oracle_script"=true;   Session altered.   orclz> create user c##garb identified by 1;   User created.   orclz>

Is the behaviour documented anywhere? I googled and found this article: Pete Finnigan's Oracle security weblog which suggests that the user would be marked as an oracle maintained and the common column of dba_users would be incorrect.

Considering the amount of issues already posted by James today due to lack of understanding of the multitenant architecture, I think this is a dangerous suggestion.

That is another of Oracle's undocumented 'features' that they used as an internal 'solution'.

In the latest version of 12c they have removed the 'prefix' restriction for common users. You can now configure your own 'common user prefix' or configure it to an empty string if you want.

So that parameter isn't of any real value to non-oracle users now anyway.

>>orclz> alter session set "_oracle_script"=true;

Something that I would NOT recommend.

Hemant K Chitale

Andrew Sayer wrote:
JohnWatson2 wrote:
Set the necessary parameter, and yu can do what you like:

 
Is the behaviour documented anywhere? I googled and found this article: Pete Finnigan's Oracle security weblog  which suggests that the user would be marked as an oracle maintained and the common column of dba_users would be incorrect.
Considering the amount of issues already posted by James today due to lack of understanding of the multitenant architecture, I think this is a dangerous suggestion.

It's not dangerous, that's the way how multitenant is installed.. the problem is just that a local user should be created in a PDB and not in the root..

I would rather suggest to the user to read the documentation, because when you have privileges and you are connected to a pdb you can create a user like "create user john identified by oracle"

It's not dangerous, that's the way how multitenant is installed

Yes - it IS dangerous. Anytime you use an undocumented feature of Oracle it is dangerous. Their use is NOT supported by Oracle so you might find yourself in a situation with a serious problem and that expensive support contract you paid for is suddenly no good. That could CERTAINLY be a danger to your org.

Oracle is making a VERY SPECIFIC use of that hint and is using it ONLY for the system accounts they create. The devs at Oracle ARE supported by Oracle if there is a problem.

.. the problem is just that a local user should be created in a PDB and not in the root.. 

Not correct - a local user MUST BE created in a PDB and not in the root.

Users created in the root are, by definition COMMON users. The newest Oracle version allows you to define the prefix to use for common users and you can choose to use an empty string. But any user you create in the root will still be a common user whether you use a prefix or an empty string for the prefix.

Come on, guys. It is pretty obvious that James is not running Oracle on a licensed system that is under support. So doing things that are "unsupported" is not an issue.

Studying Oracle means reverse engineering features and experimenting with various techniques (documented and not) for using the database, so if something will help someone to learn, go do it.  This forum is not an official support site for licensed installations. I am sure everyone here does things on their own unsupported unlicensed learning environments that they would never do at a customer site.

Well, as you say. We are not at the certification, I am sorry I didnt use the magic word..

rp

now imagine a case, how would you install multitenant without all components? ...by generating the scripts and not execute the scripts that create them.. so, in this case you can even modify the pdb$seed.. or you upgrade to 12c and a fix goes crazy, so when you know the number you disable it.  Of course such things do experts, not someone who started 2 hours ago a database

Hi,

>>  how can i create user without c##  in 12c

If it's an application user (application schema, user to connect to the application) then create it in a PDB.

If it's an admin user (DBA, monitoring, etc) then better to prefix it with C##

The goal of the prefix is to prevent problems when you move PDBs across CDBs.

Regards,

Franck.

JohnWatson2 wrote:
Come on, guys. It is pretty obvious that James is not running Oracle on a licensed system that is under support. So doing things that are "unsupported" is not an issue.

I don't see anything 'obvious' in what OP posted that even remotely suggests whether a licensed/unlicensed system is being used.

What I see in the question/issue is an exception because of not understanding the difference between common and local users in 12c - an issue that did NOT exist in previous DBs.

I see someone wanting to do something seemingly 'simple' and having it failed when it always worked in prior versions.

What I do NOT see is someone intentionally wanting to use undocumented/unsupported features to see how Oracle works.

but in this topic you have the clarification too why it's not working.. providing more interresting stuff like basics can open him a new door to go deep into oracle.. who knows.. I see here that a lot of people just answer questions, but without a background why would they do it this way and not the other

psorger wrote:
but in this topic you have the clarification too why it's not working.. providing more interresting stuff like basics can open him a new door to go deep into oracle.. who knows.. I see here that a lot of people just answer questions, but without a background why would they do it this way and not the other

That door should only be opened when you can understand the basics. Completely skipping the basic task of creating the user in the pdb is not beneficial. understanding the differences caused by multitenant architecture are essential if OP wishes to do dba tasks using it.

but in this topic you have the clarification too why it's not working

Yes - one of those 'clarifications' was my first reply where I told OP why it was 'not working' and provided them links to the Oracle that explained it and to other forum threads where the same question had been answered before.

.. providing more interresting stuff like basics can open him a new door to go deep into oracle

I certainly agree that such 'exploration' can be interesting and informative.

But the dangerous part comes in if you elect to use such an undocumented 'feature'. Use of undocumented/unsupported features CAN violate your support agreement. If you request support and Oracle discovers you have used such a feature they can decline to provide that support or may only provide it at additional cost. That can put your company at risk.

Such functionality (e.g. this one) is often designed and used by Oracle for a single, specific purpose. It has likely been tested and known to work properly for that specific purpose. It may not work properly at all if used for some other purpose - even one similar to the intended purpose.

There are at least two likely reasons they are undocumented: 1) they have not been tested for general use, 2) they are not intended, or ready, for general use.

Nothing at all wrong with doing research and trying things to see what happens. As long as you abide by the license agreements for the product. At the extreme end there could be legal consequences for publishing the results of such 'reverse engineering' - though I would expect that to be a rare exception.

I see here that a lot of people just answer questions, but without a background why would they do it this way and not the other

EXACTLY MY POINT! That is why I said this particular answer was dangerous:

Set the necessary parameter, and yu can do what you like:

There was NO mention at all of why you should NOT do it that way:

1. undocumented - there may be other factors that can affect the proper use

2. unsupported - may violate your support agreement

3. may not have been tested adequately for general purpose use

So anyone thinking they can just use that parameter and then 'do what you like' could be in for a rude awakening.

I have no problem at all with people posting any info they think might be helpful to someone asking questions or presenting a problem/issue they want help with.

I do have a problem when they don't alert people to the risks of using that info.