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

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.  

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. 

- John 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Carlos Guzmán Álvarez
Sent: Tuesday, February 28, 2006 1:37 PM
To: [email protected]
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 
> wrapper around GetOrdinal to specify the thread culture neutrally 
> 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 = 0; i < this.fields.Count; i++)
            {
                // if (GlobalizationHelper.CultureAwareCompare(name,
this.fields[i].Alias))
                if (name.ToLower().Trim() ==
this.fields[i].Alias.ToLower().Trim())
                {
                    return i;
                }
            }
                       
            throw new IndexOutOfRangeException("Could not find specified
column in results.");
        }

And let me know if it works or not ??, please :)
>  


--
Carlos Guzmán Álvarez
Vigo-Spain

http://carlosga.blogspot.com/





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Firebird-net-provider mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Reply via email to