Hello Carlos, unfortunately I can't build the provider here at this =
As soon as I get two product releases out the door that are long overdue =
plan to get involved with the provider project, for now I'm just a =
of it. :)
Since I use a Data Access Layer in my app to support MS SQL and FireBird =
was easy to do simple workaround in my Firebird DataReader wrapper =
public int GetOrdinal(string index)
Which I can confirm works perfectly in my situation, however that =
work for a Danish or Norwegian field named defined as "aAXXX" since it =
be literally interpreted as lowercase a followed by uppercase A, but it =
work perfectly if the intent was two letter A's as in English etc.
I'm certain that your change would fix my problem as well you're =
doing the opposite casing of what I'm doing, (however you're missing the
Invariant culture in the ToLower, not sure what affect that might have, =
used it in my workaround to be safe), but I'm guessing it would break =
or Norwegian implementations where the intent *was* to define the =
combination of "aA" in the field name. =20
To be honest I'm not sure if it's something you should fix because
technically speaking it's not broken.
I think this would require a native Norwegian or Danish FireBird user or
programmer to sort out because I know nothing about those languages, but
there is probably a commonsense rule that could be applied.
It's a weird issue really because typically most users of the provider =
probably targetting their native language for the most part and it's
perfectly fine in that sense. If a Norwegian user defines a field as
"aAXXX" and refers to it as that in their code using GetOrdinal then =
have no problems, if an English language user does the same thing they =
no problems. It's only when the ultimate end user has a different =
defined that it's an issue. =20
We make apps that are sold world-wide and the database fields internally =
defined in English so we're in a bit of a non usual situation probably =
most of your users.
And the database fields *are* all in single case ultimately in Firebird, =
just mix the case for readability in the source code.
Probably the only safe solution and what I would do if I were in your =
is give the ability to somewhere define the culture to use as a default =
anything related to column names etc. You could provide an overload of
GetOrdinal with a culture specifiable but then everyone would always =
use it to be safe. Perhaps a "database culture" you could set that =
"stick" for the session?
I'm not sure either way, but I would think twice before making a change =
that to it, it could be a breaking change for any of the nine cultures
specified in that MSDN article I linked in my first post.=20
[mailto:firebird-net-provider-admin@...] On Behalf Of
Carlos Guzm=E1n =C1lvarez
Sent: Tuesday, February 28, 2006 1:37 PM
Subject: Re: [Firebird-net-provider] Warning: FbDataReader.GetOrdinal =
is culture sensitive, any suggestions?
> Or is there a better way to handle this in general, maybe put a=20
> wrapper around GetOrdinal to specify the thread culture neutrally=20
> temporarily or ....?
The best is to fix it in the provider ;)
Can you make a test by modify the GetOrdinal method as:
public override int GetOrdinal(string name)
for (int i =3D 0; i < this.fields.Count; i++)
// if (GlobalizationHelper.CultureAwareCompare(name,
if (name.ToLower().Trim() =3D=3D
throw new IndexOutOfRangeException("Could not find specified
column in results.");
And let me know if it works or not ??, please :)
Carlos Guzm=E1n =C1lvarez