Error conectando Erwin 7 con SQL Server 2005

Para solucionar el problema , debemos tirar la dll NTWDBLIB.DLL enel directorio System32. Esta dll viene en el cd de instalacion del SQL Server 2000 (o la pueden bajar desde este link http://www.dlldll.com/ntwdblib.dll_download.html)

Generar Dataset en base a un XML

En el siguiente ejemplo , armaremos un Dataset partiendo de una cadena que contiene codigo XML.
// Cadena con codigo XML
string xmlData = @"
El Perro Cristiano
5.95
";

// Create the reader.
XmlTextReader reader = new XmlTextReader(new StringReader(xmlData));
// No se devuleven nodos en blanco
reader.WhitespaceHandling = WhitespaceHandling.None;
// Arma el Dataset en Base al documento XML
datos.ReadXml(reader);


// Recorro registros
foreach (DataRow registro in datos.Tables[0].Rows)
{
// Proceso cada Registro Generado
}

FACTORY PATTERN

Este pattern se utiliza para la creación de objetos , nos permite la creación de clases sin especificar la clase exacta del objeto a ser creado. Este pattern define una interfase para crear un objeto, pero las subclases son las que deciden que clase instanciar.

Ejemplo :


public abstract class Empleado
{
// Este metodo va a ser implementado en las clases
// que van a heredar de Empleado
public abstract int Sueldo();

public enum TipoEmpleado
{
Programador,
Funcional,
Analista
}

// Aca implementamos Factory , este va a devolver Empleados
// que se generan segun el parametro recibido.
// El resultado siempre sera el mismo (Empleado) , varia la
// forma en como se genera la clase.
public static Empleado EmpleadoFactory(TipoEmpleado tipo)
{
// Segun el tipo recibido generamos el objeto Empleado
// de una clase en particular
switch (tipo)
{
case TipoEmpleado.Programador:
return new Programador();
case TipoEmpleado.Funcional:
return new Funcional();
case TipoEmpleado.Analista:
return new Analista();
}
throw new Exception("Tipo no Valido");

}

}


public class Programador : Empleado
{
public override int Sueldo()
{
return 15;
}
}

public class Funcional : Empleado
{
public override int Sueldo()
{
return 20;
}
}

public class Analista : Empleado
{
public override int Sueldo()
{
return 30;
}
}


Codigo Cliente :

static void Main(string[] args)
{
// De la Factory Empleado hacemos que nos devuelva
// un Empleado del tipo programador
Empleado programador = Empleado.EmpleadoFactory(Empleado.TipoEmpleado.Programador);

Console.WriteLine("Sueldo Programador :" + programador.Sueldo().ToString());


// De la Factory Empleado hacemos que nos devuelva
// un Empleado del tipo funcional
Empleado funcional = Empleado.EmpleadoFactory(Empleado.TipoEmpleado.Funcional);

Console.WriteLine("Sueldo Funcional :" + funcional.Sueldo().ToString());


Console.ReadLine();
}

ABSTRACT FACTORY PATTERN

Este patrón se utiliza cuando debemos generar distintas familias de objetos , dejando esto a la interface de la factory y sacándole dicha responsabilidad al cliente.

El cliente tan solo de dedica a crear un determinado tipo de objeto , mientras que la abstract factory se dedica a implementar y especificar a que familia pertenece el mismo .De esta forma podemos generar objetos del mismo tipo , pero generados desde distintas clases .O se tienen distintas implementaciones y estas son manejadas por la Factory.

El siguiente ejemplo , consta de una clase Abstract Factory que nos permite generar Empleados y Clientes .En base a esta clase generamos las Factory de Personas según la Empresa (mediante herencia), que estas serán las que implementen los métodos para crear las clases Clientes y Empleados .Cada una de estas Factory lo implementara según sus propias reglas .O sea acá es cuando la factory implementa el objeto según la familia que corresponda , sabiendo que siempre va a devolver un Cliente o Empleado , sin esto estar atado a la Empresa que lo genere .Esto hace que el cliente que consuma el factory solo se preocupa por instanciar la clase que necesite , mientras que la factory se encarga de la generación de la misma.

Codigo Clase Factory :



namespace AbstractFactoryPatternLibrary
{
public abstract class PersonaFactory
{
// Nos aseguramos de que todas las clases Factory van
// a generar objetos del tipo Empleado y Cliente
public abstract Empleado BuildEmpleado();
public abstract Cliente BuildCliente();
}


// Implementamos Abstract Factory
// Mediante PersonaFactory sabemos los
// objetos que debe generar la clase.
// En este caso es una factory que lo implementa
// segun los requerimientos de Empresa1
public class Empresa1PersonaFactory:PersonaFactory
{
// Implementamos los contructores que devuelven
// los objetos establecidos en la Abstract Factory
// En este caso se generan para el empleado tipo
// EmpleadoEmpresa1
public override Empleado BuildEmpleado()
{
Empleado emp = new EmpleadoEmpresa1();
return emp;
}

public override Cliente BuildCliente()
{
Cliente cli = new ClienteEmpresa1();
return cli;
}
}



// Cumple el mismo proposito que Empresa2PersonaFactory.
// Aca podemos ver como este pattern nos permite realizar
// una implementacion distinta del primer Factory , generando
// los mismos tipos de clases hacia el cliente , pero creandolo
// desde otras clases.
public class Empresa2PersonaFactory : PersonaFactory
{
public override Empleado BuildEmpleado()
{
Empleado emp = new EmpleadoEmpresa2();
return emp;
}

public override Cliente BuildCliente()
{
Cliente cli = new ClienteEmpresa2();
return cli;
}
}




public class ClienteEmpresa1:Cliente
{
public override void VerificarCuenta()
{
Console.WriteLine("Verificando Cuenta cliente Empresa1");
}
}

public class EmpleadoEmpresa1:Empleado
{
public override void CalcularSueldo()
{
Console.WriteLine("Calculando Sueldo empleado Empresa1");
}
}

public class ClienteEmpresa2:Cliente
{
public override void VerificarCuenta()
{
Console.WriteLine("Verificando Cuenta cliente Empresa2");
}
}

public class EmpleadoEmpresa2:Empleado
{
public override void CalcularSueldo()
{
Console.WriteLine("Calculando Sueldo empleado Empresa2");
}
}


// Clases abstract , van a ser las clases base
// Desde donde van a heredar los Clientes y
// Empleados de TODAS las Empresas.
// De esta forma cada Empresa va a definir el
// campo segun sus reglas de negocio.
public abstract class Empleado
{
// Las clases van a tener que implementar este metodo
public abstract void CalcularSueldo();
}

public abstract class Cliente
{
public abstract void VerificarCuenta();
}
}


Codigo Aplicacion de Consola que consume nuestro Factory :

class Program
{
static void Main(string[] args)
{

// Generamos Factory de Personas para Empresa1
// mediante este objeto vamos a poder generar Clientes y Empleados
// con la estructura que implementa la Empresa1
PersonaFactory personaFactoryEmpresa1 = new Empresa1PersonaFactory();

// Utilizamos la Factory para generar Clientes y Empleados
Cliente clienteEmpresa1 = personaFactoryEmpresa1.BuildCliente();
Empleado empleadoEmpresa1 = personaFactoryEmpresa1.BuildEmpleado();

empleadoEmpresa1.CalcularSueldo();

// Factory para CLientes y Empleados del tipo Empresa2
PersonaFactory personaFactoryEmpresa2 = new Empresa2PersonaFactory();

//Generamos Clientes y Empleados para Empresa2
Cliente clienteEmpresa2 = personaFactoryEmpresa2.BuildCliente();
Empleado empleadoEmpresa2 = personaFactoryEmpresa2.BuildEmpleado();

clienteEmpresa2.VerificarCuenta();
empleadoEmpresa2.CalcularSueldo();

// Otro ejemplo

// En la clase Gestor tenemos un metodo que no espera un Cliente
// ni un Empleado.El mismo se encarga de Generarlos , tan solo nesesita
// un objeto Factory.
// Por lo que este Metodo queda abierto a que se le pueda pasar cualquier
// Factory sin importar la Empresa
Gestor miGestor = new Gestor();

miGestor.GenerarCliente(personaFactoryEmpresa1);

Console.ReadLine();

}
}

class Gestor
{
public void GenerarCliente(PersonaFactory persona)
{
Cliente cliente = persona.BuildCliente();
Console.WriteLine("Cliente Generado desde el Gestor");
}
}

Configurar Server Application mediante un archivo de configuración

Además de poder configurar un Remote Object mediante programación , también podemos hacerlo con un archivo de configuración (esto nos permite realizar modificaciones sin tener que recompilar nuestra aplicación)

El método Configure de la clase RemotingConfiguration nos permite indicarle desde donde va a tomar nuestro archivo de configuración .Este tiene dos parámetros el primero es el nombre del archivo y el segundo parámetro es boolean y indica si se utiliza seguridad.

Ejemplo :

RemotingConfiguration.Configure(“MyServerApplication.exe.Config”,false);

Nuestro archivo de configuración debe incluir una sección .

Es necesario especificar el hosting application, mediante el elemento , se puede especificar el nombre de la aplicación .Si nuestra aplicación corre bajo IIS no debemos setear este elemento , el IIS asume que el nombre va a ser el mismo que el root.

Dentro de , existen nodos hijos que especifican la configuración del hosting application, a continuación enumeramos algunos :

• : Solo se utiliza cuando tenemos objetos del tipo client-activated
• : Sirve para configurar uno o mas canales de comunicación
• : Lo usamos para registrar los remote objects .Esto va a ser lo que exponemos a las otras aplicaciones .Podemos especificar uno o mas.El elemento especifica los Server-activated objects, especifica los client-activated objects

Ejemplo : En la imagen del post tenemos el caso de una Configuración de un Remote Object del tipo Singleton , también registramos un TCP Channel

TSQL : Utlizar clausula In con una variable que contiene mas de un valor

La situación es la siguiente , tenemos un stored Procedure que recibe una variable del tipo varchar , en esta tenemos concatenados varios valores (separados por coma) los cuales queremos buscar dentro de un campo en una determinada tabla.La solucion es implementas en el WHERE de la consulta una sentencia del tipo :

WHERE Campo in(‘Valor1’,’Valor2’)

Pero si en la condición IN le ponemos una variables con mas de un valor , no va a funcionar.
A continuación un par de soluciones , en ambas tratamos de buscar todos los registros de la tabla CLIENTES en los cuales el campo Codigo tenga el valor ‘01’ u ‘02’

Para SQLServer 2005 :

DECLARE @itemList xml
SET @itemList = '0102'
SELECT * FROM CLIENTES WHERE Codigo IN (
SELECT t.v.query('.').value('.','VARCHAR(50)')
FROM @itemList.nodes('values/value') AS t(v)

);

Para todos los SQL :

DECLARE @ID VARCHAR(MAX)
SET @ID = '''01'',''02'''
DECLARE @SQLQUERY VARCHAR(MAX)
SET @SQLQUERY = 'SELECT * '
+ 'FROM CLIENTES '
+ ' WHERE Codigo IN (' + @ID + ')'

EXEC (@SQLQUERY)

Remoting.Configuration Class

Obtenemos acceso a esta clase cuando seteamos una referencia a System.Runtime.Remoting. mediante esta clase tenemos acceso a configuración mediante programación .A continuación se muestran un par de ejemplos de lo que nos permite configurar esta clase.

Estas son algunas de las propiedades:

• ApplicationID : Obtenemos el ID de la aplicación actual que se esta ejecutando
• ApplicationName : Obtenemos o seteamos el nombre de la aplicación
• CustomErrorsMode : Obtenemos o seteamos un valor que indica como van a ser manejados los errores .Puede ser On ,Off,o remote Orly.
• ProcessID : Obtiene el Id del actual proceso que se esta ejecutando

Especificando el nombre de un Server Application :
RemotingConfiguration.ApplicationName = "MyRemotingObject";

Registrando el Objeto Remoto :

La clase RemotingConfiguration nos da varios métodos para poder registrar nuestros objetos .A continuación se mencionan algunos.

• RegisterActivatedClientType : Registra el objeto en el cliente que se va a activar en el cliente.
• RegisterActivatedServiceType : Registra el objeto en el servicio y puede ser activado desde el cliente.
• RegisterWellKnowClientType : Registra un single-call o Singleton object en el cliente
• RegisterWellKnowServiceType : Registra un single-call o Singleton object en el service

Ejemplo registrando un Service-Activated del tipo Singleton :

RemotingConfiguration.RegisterWellKnownServiceType(typeof(Server.MyRemoteClass), "MyRemotingObject", WellKnownObjectMode.Singleton);

Ejemplo registrando client-Activated :

RemotingConfiguration.RegisterActivatedServiceType(typeof(Server.MyRemoteClass));

Configurando la Version :

Usando la propiedad TypeName podemos especificar la version del assembly de los remote Objects,en el caso de no especificarlo se toma la ultima versión publicada.

Ejemplo :

RemotingConfiguration.RegisterWellKnownServiceType(typeof(Server.MyRemoteClass,Version=1.0.0.0), "MyRemotingObject", WellKnownObjectMode.Singleton);

Registrando un Canal de Comunicacion :

Estos son usados para procesar mensajes que son enviados entre los objetos remotos.La clase ChannelService es usada para acceder a el metodo RegisterChannel,que registra un canal con channel services.A continuacion un par de reglas basicas para aplicar con channel services:

• Una aplicación Hosting puede registrar uno o más canales, pero un canal puede solamente ser registrado en el mismo puerto.
• Dos canales en la mismo application domain no pueden ser registrados con el mismo nombre.
• Por default el canal HTTP es llamado http y lo mismo con TCP , en el caso de querer registrar dos canales con el mismo nombre ,debemos setear el nombre de la segunda stancia con la propiedad ChannelName

Ejemplo registrando un canal tcp :

//Registro TCP Chanel
IChannel tcpChannel = new TcpChannel(8005);
ChannelServices.RegisterChannel(tcpChannel, false);

REMOTING

A continuación algunos conceptos básicos de remoting.

Remoting nos permite llamar objetos que existentes en diferentes maquinas ,solo si residen en la misma aplicación .Los objetos son pasados desde un application domain a otro.

Tipos de Remote Objects :

Existen dos tipos de objetos del tipo Server-Activated (Single call y Singleton).Estos manejan la vida de los objetos remotos en el Server .El tipo Client-Activated maneja la vida en el cliente.
Tipos de Objetos :

• Single Call : Los objetos implican una sola llamada en la que el estado no se mantiene entre las llamadas de los métodos .Solo una petición es atendida a la vez y cuando el objeto no es utilizado , este es descartado.(Se crean y destruyen en cada llamada)
• Singleton : Estos objetos son usados para servir múltiples clientes y mantienen el estado entre las llamadas al método .Este tipo tiene ventaja a nivel de performance cuando el costo de crear objetos todo el tiempo es alto.(el estado del objeto permanece para todos los cliente ,solo hay un objeto)
• Client-Activate : Estos objetos solo se activan cuando son llamados por el cliente.

Hosting a Remote Server Application :

Es el responsable de registrar los objetos ,en el cual escucharemos las llamadas de los clientes. Existen 4 opciones para hostear un remote object.

• Console Application
• Windows Executable
• ASP.NET application
• Windows Services

Seleccionando un canal de Comunicación :

Los canales son usados para conectar los objetos remotos y realizar el transporte de los mensajes .Existen tres tipos de canales:

• TCP : Procesa los mensajes en forma binaria .Es la mejor opción si la aplicación corre en una intranet.
• HTTP : Este usa el protocolo SOAP para transportar mensajes .Este utiliza el xml serealizer para procesar los mensajes.
• IPC: Es la mejor opción para cuando el proceso de comunicación es dentro de la misma maquina.

Manejar estados en un WebService

Esto nos sirve para mantener valores entre las llamadas a los metodos , para esto contamos con dos formas de hacerlo Application o Session Objects.

Application Object :

Es usado para guardar un valor , que puede ser accedido por todas las sesiones que atienda nuestro WebService.
Por ejemplo , esto nos puede servir para llevar un contador de los metodos que son solicitados y este valor
va a poder ser visto desde cualquier WebMethod.Esto aplica a todos los metodos que NO tengan el atributo EnableSession=true
Dicho valor va a estar vivo dentro del servicio mientras que el IIS
(o en donde alojemos nuestro servicio) este levantado.


Ejemplo :


[WebMethod(Description="Ejemplo Application Object"]
public void InicializoApplicationObject()
{
Application["MiContador"] = 1;
}


Session Object :

En este caso el valor es especifico para cada usuario.Por ejemplo se puede usar para guardar el id del usuario.
Sin embargo para que un metodo pueda utilizar dicha valor debe definir el Atributo Enablesession en true
Al implementar session Objects nesesitamos definir cookies del lado del cliente para identificar la sesion
asociada con el estado de la session.estas cookies las debemos crear mediante codigo en el cliente.
Tener muy en cuenta este punto al pensar en implementar cookies.


Ejemplo :

[WebMethod(Description="Ejemplo session Object",EnableSession=true)]
public void InicializoSessionObject(string valor)
{
Session["UserId"] = 1;
}



A continuación les dejo un ejemplo un poco mas completo , en este caso utilizaremos Session Object.


Codigo WebService :


public class Service : System.Web.Services.WebService
{

// Asigno valor a mi variable de Session
[WebMethod(Description="Ejemplo session Object",EnableSession=true)]
public void InicializoSessionObject(string valor)
{
if (Session["MiVariableDeSesion"] == null)
{
Session.Add("MiVariableDeSesion", valor);
}
else
{
Session["MiVariableDeSesion"] = valor;
}
}

// Devuelvo valor de varible de session
[WebMethod(Description = "Ejemplo obtner valor de session Object", EnableSession = true)]
public string ValorSessionObject()
{
if (Session["MiVariableDeSesion"] == null)
return "Variable de Sesion sin Inicializar";

return (string)Session["MiVariableDeSesion"];
}


}


Codigo del cliente :

protected void Button1_Click(object sender, EventArgs e)
{
//Instancio el servicio
Service ws = new Service();

// Genero cookie
System.Net.CookieContainer cookie = new System.Net.CookieContainer();
ws.CookieContainer = cookie;

// Invoco metodo del WS
ws.InicializoSessionObject("Hola !");

// Asigno nuestra cookie con la variable de Session del WS
Session.Add("MiVariableDeSesion", cookie);

Label1.Text = "Valor de Session : " + ws.ValorSessionObject() ;

}

Visual Studio 2005 : A donde fueron a parar los templates ?

De un día para el otro…..se me fueron los queridos templates del VS 2005 , el único que había quedado era el de ASP.NET Ajax …y los demás ?

No había caso no los encontraba , hasta que me tope con otro blog , en el cual comentaba que después de instalar el VS 2008 …mágicamente desaparecían los templates del 2005.

Solución :

Copiar los ítems existentes en la carpeta

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ProjectTemplates

en

C:\ Users\Mi Usuario\My Documents\Visual Studio 2005\Templates\ProjectTemplates

Copiar los ítems existentes en la carpeta

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ItemTemplates

en

C:\ Users\Mi Usuario\ My Documents\Visual Studio 2005\Templates\ItemTemplates

Y listo ,los templates han vuelto a casa…..

Instalando la Base de Datos AdventureWorks

Dado que muchos de los ejemplos que voy a subir utilizaran la base de datos AdventurWorks (base de datos que nos propone Microsoft para llevar a cabo los ejemplos en sus cursos) , pasare a explicar como se instala la misma.

1- Bajar la Base de Datos AdventureWorks , la pueden encontrar en el siguiente Link .

2- Abrir el Enterprise del SQL Server 2005 dirigrirnos hacia la carpeta Base de Datos , boton derecho y click sobre la opcion Adjuntar (Esta es una de las formas de levantar la base en nuestro servidor SQL)



3- Ahora nos dirigimos hacia el directorio en donde nos dejo los archivos el instalador y seleccionamos el archivo .MDF




4- Veremos que en el dialogo cargo los archivos .MDF (archivo de datos) y .LDF (archivo de registro)




5- Aceptamos y podremos ver como se ajunto la base de datos AdventureWorks en nuestro Sql Server 2005





Listo , ya tenemos una Base de datos completita para hacer nuestras pruebas .....

Saludos
Maxi




Sonando : Ricardito Iorio - Cualquiera de su obra

Inicio

Me presento soy Maxi , estoy hace ya un largo tiempo trabajando como desarrollador .Actualmente me dedico al desarrollo de aplicaciones bajo la plataforma .NET 2.0 utilizando el lenguaje c#.
El propósito del blog , es ir subiendo info respecto a distintos temas de programación en .NET , como así también distintos cosas que voy descubriendo en el trabajo diario.
La idea es que este espacio me sirva como machete virtual y de paso compartirlo con quien se tope con los mismos problemas.

Advierto que los post van a tratar de ser lo mas simple y entendibles para mas que nada exponer conceptos y soluciones , simple como un machete….

Nos estamos leyendo....

p.d. : Todo este blog es dedicado a Laly , mi esposa , que me banca las horas y horas que me paso frente a la notebook investigando , diseñando,testeando,puteando..... y por sobretodo el alentarme a seguir creciendo...

Music : Compañera-Ariel Minimal