net español asp and .net localization

español - Cómo usar la misma base de datos y el mismo programa para dos configuraciones regionales diferentes en.NET



globalization and localization asp net core (3)

Tengo un programa C # que usa una base de datos de SQL Server. Ya lo estoy usando en un país que usa. como separador decimal. Ahora quiero usarlo en otro país que use, como separador decimal.

en C # ¿hay alguna configuración de nivel de aplicación que pueda cambiar o escribir algún código para que pueda usar la misma base de datos y el mismo programa? ¿o tengo que cambiar todo el código para manejar este nuevo separador decimal?

No sé cómo funciona. Básicamente, creo que habría problemas en My Sql Queries. ejemplo decir que una de mis declaraciones existentes es

insert into tblproducts(productId,Price) values(''A12'',24.10)

ahora en un nuevo país se convertirá

insert into tblproducts(productId,Price) values(''A12'',24,10)

esto generará un error

Entonces, ¿tengo que cambiar todo el código para manejar esta situación?

Gracias


En su archivo global.asax.vb, puede establecer la cultura de la carga de la página actual:

Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.CreateSpecificCulture("en-US") Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture

Esto hará que toda la funcionalidad de reconocimiento cultural funcione bien. por ejemplo, (5000.25) .ToString () usará comas vs. períodos dependiendo de la cultura que establezca. Además, la lectura de las entradas del usuario en un tipo numérico se analizará de acuerdo con sus reglas de cultura. Las fechas se mostrarán correctamente (12/9/08 vs. 9/12/08). Obtienes todo eso básicamente gratis.

Esto obviamente causa problemas cuando se habla con otros sistemas que están esperando todo en la misma cultura. Para resolver esto, escribe tus consultas con la cultura invariante:

(5000.25).ToString(CultureInfo.InvariantCulture)

Esto establecerá explícitamente ese resultado a algo con lo que Mysql pueda llevarse bien.

Nota: si tiene una capa de datos adecuada y le pasa tipos numéricos, probablemente pueda evitar una gran cantidad de este desastre.


Si creó la consulta utilizando concatenación de cadenas, use parámetros en su lugar. Entonces, en lugar de escribir:

var query = "insert into tblproducts(productId,Price) values(''" + article + "'',''" + price + '')'';

use OleDbParameters :

var query = "insert into tblproducts(productId,Price) values(?,?)" var cmd = new OleDbCommand(query, connection); cmd.Parameters.Add("@article", OleDbType.VarChar).Value = article; cmd.Parameters.Add("@price", OleDbType.Single).Value = price;

Esto le ahorrará muchos problemas, incluidos problemas de localización.


puedes hacer un par de cosas para arreglar esto.

primero, si está tomando valores desde la interfaz, está convirtiendo estos valores en un decimal. Decimal.parse es una función dependiente de la cultura y utilizará la cultura actual para analizar los valores. Por lo tanto, si CurrentCulture usa comas como separadores decimales, su conversión funcionará correctamente. Luego, cuando imprima el valor de su variable, puede especificar que el formato decimal.ToString siempre muestre como un separador.

Ah, se olvidó de agregar. También puede cambiar su análisis sintáctico para indicar Moneda, que permite comas y $ signos. por ejemplo: decimal.parse (amount, NumberStyles.Currency)