Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Culture comparison in FBDataReader [DNET406] #408

Closed
firebird-automations opened this issue Jan 18, 2012 · 5 comments
Closed

Culture comparison in FBDataReader [DNET406] #408

firebird-automations opened this issue Jan 18, 2012 · 5 comments

Comments

@firebird-automations
Copy link

Submitted by: Robert Kindl (rkindl)

Relate to DNET699

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.
Example
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.");
with
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)

Commits: 12f85a8

@firebird-automations
Copy link
Author

Commented by: Robert Kindl (rkindl)

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).

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Author

Commented by: @cincuranet

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.

@firebird-automations
Copy link
Author

Modified by: @cincuranet

status: In Progress [ 3 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.7-next [ 10462 ]

@firebird-automations
Copy link
Author

Modified by: @cincuranet

Link: This issue relate to DNET699 [ DNET699 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants