ADO .Net: Extraño error de mapeo.

Tremendo rato me tuvo entretenido un error con ADO.Net (para no decir otra cosa más fea, jaja) , que impedía hacer un Insert en una tabla. El mensaje del error era el siguiente:

No mapping exists from object type Metkas.Productos to a known managed provider native type.

Al final, me di cuenta que el paso de parámetros estaba mal. Para el valor de una parámetro yo puse la palabra reservada "this". Por ejemplo: new SqlParameter("@MiParametro", this).

Al tener this como valor para el parámetro @MiParametro, genera el error antes mencionado. Diay si!, fue un error al digitar, porque no terminé la línea de código.

Transact - SQL: Borrar todas las tablas de una base de datos en SQL Server

Una forma rápida para borrar todas las tablas de una base de datos es con el siguiente comando:

EXEC sp_MSforeachtable @command1 = "DROP TABLE ?"

Alternativamente para poder borrar todos los Procedimiento almacenados podemos aplicar el siguiente código:

declare @procName sysname

declare someCursor cursor for
    select name from sysobjects where type = 'P' and objectproperty(id, 'IsMSShipped') = 0

open someCursor
fetch next from someCursor into @procName
while @@FETCH_STATUS = 0
begin
    exec('drop proc ' + @procName)
    fetch next from someCursor into @procName
end

close someCursor
deallocate someCursor
go

WCF: The remote server returned an error: NotFound.

Infinidad de ocasiones me ha aparecido el error: The remote server returned an error: NotFound.

Caso #1:
Y no siempre, la solución es la misma para ese tipo de error. Si a alguien puedo ayudar con ésta entrada, les cuento que casi siempre es porque le estamos pasando un parámetro de un tipo X a un WCF, y el WCF está devolviendo un tipo igual al parámetro de entrada, con la excepción de que el parámetro de entrada estaba por así decirlo "extendido"; es decir, era una clase hija que heredaba de la clase padre, entonces, podemos cometer el error de devolver la clase extendida, sin embargo se suponía que el método solo retornaba el tipo de la clase padre (la clase normal y no la extendida).

No sé si me expliqué bien, pero bueno, lo dejo para acordarme como fue que solucioné mi error en C# y los WCF, jajajajaja!.

Caso #2:
De nuevo el errorcito, ésta vez era porque en el subproyecto donde tenía todos los WCF, se les estaba poniendo el sufijo WCF al final del nombre y al hacer la referencia en el proyecto de Silverlight, también estaba poniendo el mismo sufijo WCF. El detalle del por qué un WCF me estaba presentando ese error, era porque en el proyecto donde tenía todos los WCF, específicamente para el WCF que me daba el error, no le había puesto el sufijo, pero cuando hice la referencia si le puse el sufijo. Internamente la dirección "Address" estaba bien colocada, pero algún colega, le agregó el sufijo provocando el error. Bueno, por lo menos descubrí otra forma de como hacer que los WCF fallen, jaja!.

Silverlight: Subir archivos al servidor.

Un link sobre cómo subir archivos al sevidor utilizando un indicador de progreso.

.Net 3.0: ¿Vale la pena usar la palabra reservada var?

Ya hace tiempo cuando estuve trabajando con LINQ en una de las empresas que estuve, mi jefe me explicó las ventajas de usar la palabra reservada "var", que aunque no es algo así como muy milagroso, si vale la pena mencionar sus ventajas, muy pocas ventajas, pero que si me parecen muy interesantes!.

Como todos bien saben, o si no lo sabían, en .Net todas las variables deben ser fuertemente tipificadas; es decir, tenemos que especificar de qué tipo será la variable, por ejemplo: int, short, long, un tipo definido por el usuario, etc.

Ahora bien, con la entrada de la versión de .Net 3.0 aparece la palabra reservada "var" con la cual podemos declarar variables en forma implícita; esto significa que no es necesario que especifiquemos el tipo de la variable, dejando ese trabajo al compilador.

Muchos programadores pensarían que eso es una "mala práctica de programación" porque estamos forzando más trabajo para el compilador y que el producto final que se instala en producción no será eficiente, etc.

Si siguen leyendo está entrada se darán cuenta que NO ES CIERTO tal afirmación, usar var es algo normal, jaja!.

1º) Originalmente "var" se creó para utilizarlo con los tipos anónimos, que hablando de temas de LINQ se hace muy claro la existencia de "var".

2º) var se puede utilizar en cualquier código que queramos hacer, con las siguientes excepciones:

a)- Al declarar una variable implícita, siempre debemos asignarle un valor; es decir, no podemos poner:

var resultado;

Lo anterior no funciona porque el compilador no va a poder definir de que tipo debe ser la variable.

b) var, solo se puede usar dentro de métodos de una clase.

c) No es posible retonar un tipo var y los parámetros tampoco pueden ser var; es decir, si queremos definir una función tal como:

public var Cuadrado(var base){
      return base*base;
}

Lo anterior no funciona!


Ahora, las ventajas:

1º) No tenemos que estar escribiendo el tipo de la variable y ni siquiera el namespace reduciendo la línea de código en gran medida.:

     var resultado = gridDatos.ItemsSource as List<Productos>;

En el ejemplo anterior se usa la clase List genérica con el tipo Productos, donde Productos es una clase definida por el usuario. La línea de código anterior sin usar var quedaría así:

ObservableCollection<Productos> resultado = gridDatos.ItemsSource as ObservableCollection<Productos>;

Notar como se está especificando en el ejemplo anterior, el tipo en ambos lados, lo cual es entendible pero innecesario, en lo personal, ahora que conozco la existencia de var.

Ahora consideren cuando el programador gusta poner el nombre de namespace completo (sin usar alias), la línea de código quedaría extremadamente larga. Además por si no lo sabían, el optimizador del compilador quita los namespace largos y los combierte en alias o simplemente los quita y deja solo el nombre del tipo exacto sin especificar todas las partes del namespace.

2º) Como mencioné anteriormente, muchos programadores piensan que usar var no es eficiente para el producto final que entregamos al cliente; está afirmación es falsa, porque el compilador se encarga de inferir los tipos de datos donde existe var generando un ensamblado en donde reemplaza las palabras var por el tipo que se le está asignando a la variable. Es decir, los ensamblados generados son iguales si nosotros declaramos explícitamente o implícitamente las variables.

Veamos éste sencillo ejemplo donde se declara una variable usando var.

Ahora vean el código des-ensamblado, donde se observa que el compilador dedujo el tipo de datos, en éste caso es int.

Igualmente en el código MSIL (Microsoft Intermediate Language) tenemos que el tipo de datos para la variable "i" es int:

Por cierto en Visual Basic .Net, el equivalente de var es la palabra reservada Dim, por ejemplo: Dim miVariable = 5 * 5.

Referencia:

El excelente libro que leí hace mucho tiempo: LINQ IN ACTION de Fabrice Marguerie, Steve Eichert y Jim Wooley.