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

Just a point, SQL is case sensitive.  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,  
and you must type the name correctly when dealing with them in a  
programatic environment.

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