creo que de confrontación no se proporciona en las versiones actuales de SQLite. Como tal, parece que el plan más sensato es eliminar el género de la consulta y, en su lugar, ordenarlo en .Net puro, donde tienes control total y acceso a construcciones como la información cultural de la secuencia.
Dado que ambos están sucediendo en el mismo proceso, esto no debería marcar una gran diferencia en términos de rendimiento a menos que el conjunto de datos sea muy grande.
SQLite 3 permite las funciones de intercalación definidas por el usuario, y esto se puede hacer en SQLite.Net como funciones .NET, pero la sobrecarga de llamadas hacia adelante y hacia atrás a través del límite gestionado/no gestionado es considerable. Aquí hay uno persons attempts to do it in c++. A menos que tenga acceso a la clasificación sensible a la cultura unicode bien probada y estable de otra persona en C++, le sugiero que se apegue al tipo simple después de la aproximación siempre que sea posible.
Por supuesto, si el rendimiento de la intercalación definida por el usuario es más que suficiente para sus necesidades actuales, entonces vaya con eso.
[SQLiteFunction(Name = "CULTURESORT", FuncType = FunctionType.Collation)]
class CultureSort : SQLiteFunction
{
public override int Compare(string param1, string param2)
{
return String.Compare(
param1,param2, CultureInfo.CurrentCulture, CompareOptions.IgnoreCase)
);
}
}
Posdata si te apetece lujo: Hay una acumulación bendito de SQLite, que integrates the ICU library de apoyo 'adecuado' Unicode al efectuar el pedido/como/superior/inferior, sino que tendría que integrar esto en el código SQLite utilizado como respaldo para el contenedor .Net. Esto no es fácil.
toooo lenta) convertir cadena entera sólo para usar primer par de caracteres –
Quizás quiso probarlo? La conversión ocurre en el lado de SQL. – Rover
Sí. No creo que MSIL se interprete de manera diferente en ninguno de los lados. –