c# - que - llenar dataset vb net

Tipos anulables en tablas de datos/conjuntos de datos de tipo fuerte: ¿soluciones alternativas?

Question

Los DataTables de tipo fuerte admiten tipos de campo "anulables", excepto que el diseñador no le permitirá cambiar la configuración para "permitir valores nulos" para cualquier campo de tipo de valor. (Es decir: los tipos de cadena permiten nulos, pero no los de int).

La solución es llamar a IsMyFieldNull () cada vez que desee obtener Myfield. Si accede a MyField cuando contiene un valor nulo, arroja una ecepción.

Este es un dolor de cabeza masivo, además de causar muchos errores de tiempo de ejecución cuando una aparición nula puede hacer que su aplicación se bloquee. Me quejé con Microsoft desde hace años por esto, sin embargo, cada nueva versión de Visual Studio aún no permite el uso de tipos de valores anulables.

Mi pregunta: ¿Alguien sabe de uno o más métodos de extensión sofisticados que podrían usarse para solucionar este problema importante?

Answer 1

En VS 2008, solo puede ingresar un ''0'' en la propiedad nullvalue.
Si está utilizando vs2005, debe hacerlo con un editor XML. Debe agregar msprop:nullValue="0" como atributo a la columna.

Answer 2

Estoy de acuerdo en que sería una buena característica para permitir tipos anulables.

Si establece la propiedad "NullValue" en la columna en "-1" en lugar de "(Excepción de lanzamiento)", la propiedad devolverá un -1 cuando la columna sea nula en lugar de lanzar una excepción. Todavía tienes que configurar la columna para permitir nulos.

Alternativamente, siempre puede establecer el tipo de datos a "System.Object", y permitir nulls = true. Puede acceder al valor de la columna sin tener que usar el método "IsMyFieldNull ()". El valor de la columna será "System.DbNull.Value" cuando la columna sea nula. Si no le gusta usar "System.DbNull.Value", puede establecer la propiedad "NullValue" en "(Nothing)" en lugar de "(Throw exception)" y luego comparar el objeto con una referencia nula.

Answer 3

Los tipos anulables se introdujeron en .net 3.0, estos pueden usarse con conjuntos de datos. Usted declara un int Anulable como este int? myNullableInt = null int? myNullableInt = null Aquí hay un enlace al artículo de MSDN: Tipos anulables C #

Personalmente, me mantendría alejado de los nulos en las bases de datos en primer lugar (si tiene el lujo de hacerlo). NULL está realmente allí para permitir un estado "No definido" o "Desconocido". Es raro tener este problema, por ejemplo, un campo de cadena que contiene un apellido a menudo se configurará en valores nulos, mientras que el valor predeterminado en "" sería una opción mucho mejor. Poner valores nulos en las bases de datos hace que las cosas sean innecesariamente difíciles. Valores nulos En las bases de datos , además, propaga valores nulos en el código y tiene que trabajar para evitar excepciones de referencia nulas.

Desafortunadamente, hay muchas cosas malas escritas en Internet sobre bases de datos (como el uso excesivo de null como correcto). Estos puntos de vista normalmente son de personas que realmente no entienden la teoría que los respalda, otro ejemplo clásico es una base de datos sin relaciones "porque es más flexible / rápido de manejar en el código". Esto significa que el desarrollador tiene que volver a escribir la funcionalidad existente [capa de base de datos] que la inevitabilidad de la base de datos maneja de manera más eficiente y con mucha mayor confiabilidad. Digo inevitabilidad ya que, por supuesto, el desarrollador que está haciendo la reescritura está re-implementando cosas que Oracle / Microsoft / Whoever han tenido grandes equipos que pasan mucho tiempo optimizando, etc. Sin embargo, de vez en cuando, alguien defiende esto como un diseño. Este tipo realmente entiende las bases de datos, DBDebunkings pasó mucho tiempo tratando de desacreditar muchos argumentos sin sentido que alejan las bases de datos relacionales de sus raíces teóricas.

Answer 4

No estoy seguro de por qué var x = !IsMyFieldNull() ? MyField : null var x = !IsMyFieldNull() ? MyField : null (o similar) es un dolor de cabeza.

Supongo que podría escribir un envoltorio alrededor de SqlDataReader para atrapar esos valores nulos de alguna manera cuando lea los datos en su DataTable, o podría escribir el equivalente de .TryParse() para sus consultas: algo agradable y encapsulado como:

var x = myDataTable.TryParse(myField);

donde .TryParse es un método de extensión que se parece a algo como:

public static TryParse(DataRow myField)
{
    if(!myField == DbNull) //Or similar
       return myField.Value;
}

Esto es, como puede ver, básicamente un pseudocódigo en bruto, pero entiendes la idea. Escriba su código una vez, luego llámelo como un método de extensión.

Answer 5

Podría hacer esto: establezca AllowDbNull en true, si no está configurado; DefaultValue permanece activado; NullValue permanece activado (excepción de lanzar). Luego, a partir del código, cuando desee establecer en nula una columna, puede usar el método integrado Set_Column_Null (). Mira mi ejemplo:

if (entry.PosX.HasValue)
    newRow.PosX = entry.PosX.Value;
else
    newRow.SetPosXNull(); 

Answer 6

Si está utilizando .Net 3.5 o superior, puede ser que estas extensiones le sean de utilidad: http://msdn.microsoft.com/en-us/library/system.data.datarowextensions.field.aspx

Según la documentación, es totalmente compatible con los tipos anulables. Te permite usar constructos como

MyRow.Field<int?>("MyField") 

y si lo asigna ao desde una variable existente del tipo correcto, el compilador puede inferir el tipo automáticamente y usted puede omitir el especificador de tipo, haciéndolo tan corto como

int? myVar = MyRow.Field("MyField");
MyRow.Field("MyField") = myVar;

Aún no es perfecto, pero es mucho más legible que tener que usar IsMyFieldNull () etc. en todas partes.

Ah, y si quieres estar más seguro con respecto a los nombres de las columnas de ortografía, puedes usar cosas como

MyRow.Field(MyTable.MyFieldColumn)

No olvide agregar una referencia a System.Data.DataSetExtensions .

Answer 7

Solo tenía que encontrar una solución para esto. Necesitaba cambiar algún código antiguo para una página web, escrito para ASP.NET 2.0. La página utiliza Telerik RadMenu, un control de menú. Este componente requiere que los elementos raíz tengan valores DBNull adecuados (para los ID de padres). Entonces, cuando compilé el código anterior, el componente RadMenu me dio muchos problemas. Primeras excepciones con respecto a Restricciones, luego no entendía qué elementos eran elementos raíz y todo parecía horrible.

Pero lo resolví y esto es lo que funcionó para mí.

En la página de propiedades de la columna ParentID en el diseñador del adaptador de tabla, utilicé: - AllowDBNull: true - DefaultValue: -1 (-1 es un valor que no ocurre normalmente para esa columna) THe NullValue-property se mantuvo en "Excepción Throw "como era imposible cambiar para mí.

Y en el código que usa los valores del adaptador de tabla, utilicé esta construcción (código VB.NET, no C #, ya que esta pregunta está etiquetada):

Dim MenuBarTable As DAL.Page.MenuBarDataTable ''The Table Adapter
MenuBarTable = PageObj.GetMenuBar()  ''The generated Get function 
MenuBarTable.ParentIDColumn.AllowDBNull = True 

    For Each row As Page.MenuBarRow In MenuBarTable.Rows
        If row.IsParentIDNull() Then 
            row.SetParentIDNull() 
        End If
    Next

El código generado para los adaptadores de tabla genera dos funciones para cada columna que deberían permitir DBNULLs. Se utilizan para usarse cuando se trata de NULL, pero es una solución torpe de Microsoft. Lo que sucede detrás de la escena es que el adaptador de tabla generará el valor predeterminado de la columna en lugar de NULL desde la función Get. Llamo a eso un "NULL simulado" o un "NULL falso".

La función IsParentIDNull () realmente verificará si la fila contiene este "NULL falso", por ejemplo, DefaultValue de la columna, y cuando lo hace, estoy insertando un DBNull apropiado usando la función SetParentIDNull ().

Esta solución funciona para mí, pero no es muy elegante, ni es muy eficiente, pero podría ser de ayuda para otra persona, espero.