Hello Carlos, unfortunately I can't build the provider here at this =
moment.
As soon as I get two product releases out the door that are long overdue =
I
plan to get involved with the provider project, for now I'm just a =
consumer
of it. :)
Since I use a Data Access Layer in my app to support MS SQL and FireBird =
it
was easy to do simple workaround in my Firebird DataReader wrapper =
class:
----
public int GetOrdinal(string index)
{
return
InnerReader.GetOrdinal(index.ToUpper(System.Globalization.CultureInfo.Inv=
ari
antCulture));
}
-----
Which I can confirm works perfectly in my situation, however that =
wouldn't
work for a Danish or Norwegian field named defined as "aAXXX" since it =
will
be literally interpreted as lowercase a followed by uppercase A, but it =
does
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 =
basically
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, =
I
used it in my workaround to be safe), but I'm guessing it would break =
Danish
or Norwegian implementations where the intent *was* to define the =
special
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 =
are
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 =
they
have no problems, if an English language user does the same thing they =
have
no problems. It's only when the ultimate end user has a different =
culture
defined that it's an issue. =20
We make apps that are sold world-wide and the database fields internally =
are
defined in English so we're in a bit of a non usual situation probably =
for
most of your users.
And the database fields *are* all in single case ultimately in Firebird, =
we
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 =
shoes
is give the ability to somewhere define the culture to use as a default =
for
anything related to column names etc. You could provide an overload of
GetOrdinal with a culture specifiable but then everyone would always =
need to
use it to be safe. Perhaps a "database culture" you could set that =
would
"stick" for the session?
I'm not sure either way, but I would think twice before making a change =
like
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
- John=20
-----Original Message-----
From: firebird-net-provider-admin@...
[mailto:firebird-net-provider-admin@...] On Behalf Of
Carlos Guzm=E1n =C1lvarez
Sent: Tuesday, February 28, 2006 1:37 PM
To: firebird-net-provider@...
Subject: Re: [Firebird-net-provider] Warning: FbDataReader.GetOrdinal =
Method
is culture sensitive, any suggestions?
Hello:
> 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)
{
this.CheckState();
for (int i =3D 0; i < this.fields.Count; i++)
{
// if (GlobalizationHelper.CultureAwareCompare(name,
this.fields[i].Alias))
if (name.ToLower().Trim() =3D=3D
this.fields[i].Alias.ToLower().Trim())
{
return i;
}
}
=20
throw new IndexOutOfRangeException("Could not find specified
column in results.");
}
And let me know if it works or not ??, please :)
> =20
--
Carlos Guzm=E1n =C1lvarez
Vigo-Spain
http://carlosga.blogspot.com/
|
