Username - case sensitivity and embeded period

Question

I have been asked to investigate the impact of syncing our oracle user names with our AD names .. which would mean putting a period (dot) in the username. (example - john.doe). First attempt to create one returned an error which lead to the following testing:
SQL> conn system/****
Connected.
SQL> --
SQL> -- create a user with a dot in the name
SQL> --
SQL> create user ed.stevens identified by tiger;
create user ed.stevens identified by tiger
ERROR at line 1:
ORA-01936: cannot specify owner when creating users or rolesOk, the '.' is seen as a delimiter, so must be quoted, probably leading to case sensitivity.
SQL> create user "ed.stevens" identified by tiger;
User created.
SQL> grant create session to ed.stevens;
grant create session to ed.stevens
ERROR at line 1:
ORA-00933: SQL command not properly ended
SQL> grant create session to "ed.stevens";
Grant succeeded.
SQL> select username
  2    from dba_users
  3    where upper(username) like 'ED%'
  4    order by 1;
USERNAME
ed.stevens
1 row selected.Now let's do it with an upper case name
SQL> --
SQL> create user ED.STEVENS identified by lion;
create user ED.STEVENS identified by lion
ERROR at line 1:
ORA-01936: cannot specify owner when creating users or roles
SQL> create user "ED.STEVENS" identified by lion;
User created.
SQL> grant create session to ED.STEVENS;
grant create session to ED.STEVENS
ERROR at line 1:
ORA-00933: SQL command not properly ended
SQL> grant create session to "ED.STEVENS";
Grant succeeded.
SQL> select username
  2    from dba_users
  3    where upper(username) like 'ED%'
  4    order by 1;
USERNAME
ED.STEVENS
ed.stevens
2 rows selected.Everything to here makes sense. Now lets' try to connect as these two nefarious characters!
SQL> --
SQL> conn ed.stevens/tiger
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
SQL> select user from dual;
SP2-0640: Not connected
SQL> conn "ed.stevens"/tiger
Connected.
SQL> select user from dual;
USER
ed.stevens
1 row selected.
SQL> --
SQL> conn ED.STEVENS/lion
Connected.Whaat?? Why wasn't the '.' seen as a delimiter here? This is the question that this example was leading to.
SQL> select user from dual;
USER
ED.STEVENS
1 row selected.
SQL> conn "ED.STEVENS"/lion
Connected.
SQL> select user from dual;
USER
ED.STEVENS
1 row selected.
SQL> --
SQL> spool off
SQL> conn system/****
Connected.
SQL> drop user "ed.stevens";
User dropped.
SQL> drop user "ED.STEVENS";
User dropped.

Answer 1

Centinul wrote:
Ed --
I saw different behavior in my environment:
SQL> CREATE USER "cen.tinul" IDENTIFIED BY mynx;
User created.
SQL> CREATE USER "CEN.TINUL" IDENTIFIED BY mynx;
User created.
SQL> GRANT CREATE SESSION TO "cen.tinul";
Grant succeeded.
SQL> GRANT CREATE SESSION TO "CEN.TINUL";
Grant succeeded.
SQL> SELECT * FROM V$VERSION;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for 64-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> CONNECT cen.tinul/mynx
Connected.
SQL> SHOW USER
USER is "CEN.TINUL"
SQL> CONNECT CEN.TINUL/mynx
Connected.
SQL> SHOW USER
USER is "CEN.TINUL"
"This just gets curioser and curioser."
This is the system I used for the test posted above - running on 32-bit OEL under vmware on my laptop
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE10.2.0.4.0Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
5 rows selected.So I ran the test against our prod datbase, running under 64-bit HP-UX Itanium
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
5 rows selected.As for what about the two is not shown, the 32-bit Linux was built with the 10.2.0.1 base install, then the 10.2.0.4.0 patchset, then the Oct 2009 CPU - all before creating the database. The database was created from scripts using CREATE DATABASE, as generated originally by dbca (not the 'restore database' scripts from dbca when using one of their pre-defined templates.)
The HP-UX system was built as a 10.2.0.1 database, upgraded to 10.2.0.4, and has all CPU's through Jan 2010.
Both systems gave exactly the same results, which are obviously different from yours ....
A mystery wrapped in an enigma ....