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);