Re: Case sensitivity problem with primary keys in EOEditingContext.faultForRawRow

On Jul 29, 2006, at 9:49 PM, Chad Leigh wrote:

>
> On Jul 29, 2006, at 8:44 PM, Mark Morris wrote:
>
>> Just a point, SQL is case sensitive.
>
> Not according to the standard.

The standard specifies both "regular identifiers" and "delimited  
identifiers".

>
>> Various DB's do various things when you type in an unquoted object  
>> name, but behind the scenes they're case sensitive.
>>
>> For instance, if you don't quote a table name in Oracle in the  
>> CREATE TABLE statement, it will be converted to uppercase on the  
>> fly.  So you must type it in uppercase in EOModeler.  Same with  
>> attributes.
>>
>> There's a nice little table showing how various DB's handle non- 
>> quoted object names about 3/4 of the way down this page: <http:// 
>> www.4js.com/exclude/en/html/fgl/User/SqlProgramming.html>
>>
>> The automatic translation thing that most DB's do is a  
>> convenience, but doesn't change the fact that the DB is actually  
>> case sensitive,
>
> The implementation behind the scenes may be case sensitive -- that  
> is the implementors decision, but unless things are quoted they are  
> not supposed to be case sensitive to the user.

The standard actually specifies that things behind the scenes, for  
regular identifiers, are to be converted to upper case.

>
>> and you must type the name correctly when dealing with them in a  
>> programatic environment.
>
> EOF should do the right thing.  If it is defined with small letters  
> in EOF, when EOF generates the SQL to create the DB it should do so  
> quoted or it should behave in a case insensitive manner.
>
> The fact is that SQL is NOT case sensitive.

Since the standard requires that delimited, case-sensitive  
identifiers be supported, and specifies further that non-delimited,  
regular identifiers be stored in upper case, that sounds case  
sensitive to me.  And regardless of my opinion, if I go querying the  
data dictionary, I'd better get the case of the object I'm seeking  
correct if I hope to find it, since, per standard, that's how it's  
stored.

And practically, since EOF has to recognize the fact that, per  
standard, there may be mixed case or lower case names out there, the  
approach it uses is straightforward:  type it in exactly as it's  
stored in the database.

--
Mark


>
> Chad
>
>>
>> Regards,
>> Mark
>>
>> On Jul 29, 2006, at 8:40 PM, Chad Leigh wrote:
>>
>>>
>>> On Jul 29, 2006, at 6:31 PM, Sacha Michel Mallais wrote:
>>>
>>>> On Jul 29, 2006, at 9:19 AM, Marc Gumpinger wrote:
>>>>
>>>>> Now the problem - at least in my case - is, that the  
>>>>> dictionary's keys are all upper case (here "ID") since that's  
>>>>> what the database returned. However, the primary key's name in  
>>>>> the eomodel is all lower case (here "id"). For this simple  
>>>>> reason, the entire faultForRawRow doesn't work.
>>>>>
>>>>> Is there an official solution to this problem?
>>>>> I mean, it was no effort, to adopt the dictionary  
>>>>> correspondingly so that the keys also match in case  
>>>>> sensitivity. However, due to EOFs maturity I'm sure that I  
>>>>> either made a mistake or oversaw something.
>>>>
>>>> I would not call case-sensitivity a problem.  I would call that  
>>>> a feature.  If you've ever been bitten the other way, you'll  
>>>> know what I mean.
>>>
>>> Since SQL is not case sensitive (and various DBs do various  
>>> things), EOF shouldn't be either on things that deal with stuff  
>>> the DB returns.
>>>
>>> Chad
>>
>
> _______________________________________________
> EOF mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/eof