Issue Details (XML | Word | Printable)

Key: DNET-406
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Jiri Cincura
Reporter: Robert Kindl
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
.NET Data provider

Culture comparison in FBDataReader

Created: 18/Jan/12 12:03 PM   Updated: 16/Sep/16 01:09 PM
Component/s: ADO.NET Provider
Affects Version/s: 2.7
Fix Version/s: 2.7.5

Environment: Windows with Turkish Locale (tr-TR)
Issue Links:

 Description  « Hide
when I use FbDataReader to load some data from database on system with tr-TR locale it's not possible to use columns containing with character "i". It's simply because Char.ToUpper('i') does not returns I but "I with dot". So in this case "caseinsensitive" comparison is not enough.
      string description = aDataReader["ProductDescription"];

Workaround - use upper characters for I eg. - but it's awfull and hard to test
     string description = aDataReader["ProductDescrIptIon"];

I tried to do some quick&dirty fix in FBDataReader.cs in method GetOrdinal. I simple replace original code
            if (!columnsIndexes.TryGetValue(name.ToUpper(), out index))
                throw new IndexOutOfRangeException("Could not find specified column in results.");
            if (!columnsIndexes.TryGetValue(name.ToUpper(CultureInfo.InvariantCulture), out index))
                throw new IndexOutOfRangeException("Could not find specified column in results.");

but in fact, I think that best fix should be by using something like this:
String.Equals("i", "I", StringComparison.InvariantCultureIgnoreCase)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Robert Kindl added a comment - 18/Jan/12 12:06 PM
And of course there can be more places where this can cause problems, but to me it seems to work (except similar bug in native .NET DataTable which suffers with same problem).

Jiri Cincura added a comment - 04/Mar/12 07:27 AM
OK, I improved the logic little bit. The match is first trying to do ordinal CS, then ordinal CI match and then finally invariant CI. In your case, the ordinal CI will do the match.

The last option is there to help support some "normal-special" characters in your column names (does somebody use it?) and it's CI, because SQL by default is CI. If somebody needs match, that's failing on invariant culture, (s)he has to use exact name to match on ordinal match.