Home » SQL & PL/SQL » SQL & PL/SQL » Bizarre behaviour of a Function
Bizarre behaviour of a Function [message #2631] Thu, 01 August 2002 08:12 Go to next message
Mark Grimshaw
Messages: 73
Registered: June 2002
Member
I am confused as to why the following function that I have in a package repeatedly returns true even though I can invoke it with different user names on each invocation.

FUNCTION UserExists(userName IN user_users.username%TYPE) RETURN BOOLEAN IS

RecordCount NUMBER;

BEGIN
SELECT COUNT(*) INTO RecordCount FROM dba_users
WHERE dba_users.username = userName;

IF RecordCount = 0 THEN
RETURN false;
ELSE
RETURN true;
END IF;
END;

Any ideas anyone ?

Mark Grimshaw
Re: Bizarre behaviour of a Function [message #2633 is a reply to message #2631] Thu, 01 August 2002 10:17 Go to previous messageGo to next message
Todd Barry
Messages: 4819
Registered: August 2001
Senior Member
Just a note that you can collapse that return logic into just:

return (RecordCount = 1);


As far as the results go, it is impossible to provide any ideas without more data. The function itself looks fine. You would have to show us the equivalent query results outside the function - show a query with a valid user, then a non-existent user, then show the function result for both users.
Re: Bizarre behaviour of a Function [message #2638 is a reply to message #2633] Fri, 02 August 2002 03:04 Go to previous messageGo to next message
Mark Grimshaw
Messages: 73
Registered: June 2002
Member
Todd, As ever thanks for the reply.

Due to the mere fact that you replied to my question and that you prompted me to scrutinise my code I have have made 2 observations. Maybe you could comment on these observations and give me guidance.

I checked my test script and ran the query as you asked from the SQL Plus command line.

These are my results/observations:-
-------------------------------------------------------
1) User DML queries such as SELECT use CASE
SENSITIVE comparisons when comparing column
values.

I created a user fred as SYSTEM at the SQL
command prompt. I then ran the following queries
from the command prompt:

SELECT COUNT(*) FROM dba_users WHERE username=
'fred';

This returned a count of 0 !!

The following query returned a count of 1

SELECT COUNT(*) FROM dba_users WHERE username=
'FRED';

I do not understand the reasoning behind the
result for the first query when you consider
observation 2 below.

2) DDL SQL statement use CASE INSENSITIVE
comparisons.

I tried to do the following from the command
prompt:-

CREATE USER FRED IDENTIFIED BY letmein;

I got the 01920 error complaining that the
user 'FRED' conflicts with another user name or
role name.
-------------------------------------------------------
I promptly changed my test script that used the function by passing an upper case name and it worked
as expected. I understand the reasoning behind
case insensitivity of stored usernames but don't know why a query such as SELECT needs to use the correct case?

Thanks

Mark
Oh - could you point out the function to use to
convert strings to upper case as I have had enough
of reading Oracle documentation for one week.
Re: Bizarre behaviour of a Function [message #2644 is a reply to message #2633] Fri, 02 August 2002 10:49 Go to previous messageGo to next message
Todd Barry
Messages: 4819
Registered: August 2001
Senior Member
Yes, DML is always case-sensitive unless compensated for in the query (by changing the case of the column and/or the criteria). And this is a good thing.

The DDL is different in that Oracle stores all object names in uppercase by default. You may create a user like:

create user fred identified by fred;


but that user gets created internally as FRED.

sql>create user fred identified by fred;
 
User created.
 
sql>create user "fred" identified by fred;
 
User created.
 
sql>select username from dba_users where username in ('fred', 'FRED');
 
USERNAME
------------------------------
FRED
fred
 
sql>create user FRED identified by fred;
create user FRED identified by fred
            *
ERROR at line 1:
ORA-01920: user name 'FRED' conflicts with another user or role name


Oh, the function to convert to uppercase...UPPER.
Re: Bizarre behaviour of a Function [message #2651 is a reply to message #2633] Sun, 04 August 2002 06:04 Go to previous messageGo to next message
Mark Grimshaw
Messages: 73
Registered: June 2002
Member
Thanks,

I am currently writing this reply from home and so don't have my Oracle docs to hand so I have two further questions: - You say that with DDL all object names are stored as uppercase but you appeared to override that particular rule with create user "fred" ... I don't get it. Also, you you enlighten me as to why DML is case sensitive ? Is it anything to do with the ability to store usernames as lower case using the override that you demonstrated?

Thanks

Mark
Re: Bizarre behaviour of a Function [message #2661 is a reply to message #2633] Mon, 05 August 2002 08:21 Go to previous messageGo to next message
Todd Barry
Messages: 4819
Registered: August 2001
Senior Member
By using the double-quotes around the object name, I overrode the default uppercase storage. The same principle applies to objects like tables. Although legal and possible, the creation of case-sensitive (non-uppercase) object names can lead to all sorts of compatibility issues down the road with not only internal code/queries, but third-party tools.

DML is always case-sensitive because data is always stored as entered. A first name of 'Mark' is very different than 'MARK' or 'mark'. It is up to the developer to insure data consistency. If you allow names to be entered in mixed-case (which is typical), then your query to retrieve rows by name needs to be case-insensitive. This can be accomplished several ways - by uppercasing the data on the search query, storing a duplicate case-insentitive version of the column, or by using function-based indexes (IMHO, the best way).
Re: Bizarre behaviour of a Function [message #2674 is a reply to message #2633] Tue, 06 August 2002 01:48 Go to previous message
Mark Grimshaw
Messages: 73
Registered: June 2002
Member
That ties another issue up for me - thanks Todd
Previous Topic: How to count number of returning rows (with an example)
Next Topic: What I thought was a simple insert statement!!!
Goto Forum:
  


Current Time: Fri Apr 19 04:51:48 CDT 2024