Nuevo sitio!

www.thanksnetwork.com

Importar datos de un Hoja de Excel a SQL Server 2008 R2

Creo que varias veces o casi siempre almacenamos información , en hojas de calculo de excel  pero que pasa cuando se nos pide que  toda esa información sea migrada a una base de datos.

En ocasiones  no siempre sabemos por donde empezar pero en esta entrada les diré como importar esa información a la base de datos .Supongamos que tenemos nuestra hoja de excel.

Fig.1 Hoja de Calculo de Excel

Lo primero que tendremos que hacer es crear una tabla en la base de datos que contenga las columnas de nuestras hoja de calculo y definamos el tipo de dato , para ello hacemos lo siguiente localizamos el explorador de objetos Base de Datos=>

Fig.2 Nueva Tabla 

Una  vez creada la tabla en nuestra base de datos importaremos la información que esta en nuestra hoja de calculo para ello tendremos que ir a al explorador de objetos , seleccionar la base de datos, clic derecho =>Tareas=>Importar Datos y damos clic.

Fig 3. Importacion de Datos

En ese momento se abrirá una nueva ventana que es el asiente para importar datos para ello tendremos lo siguiente .

Fig.4 Asistente para importar datos

En la parte de de origen de datos seleccionamos Microsoft Excel , tendremos que seleccionar la ruta donde se encuentre no estro archivo de excel y por ultimo la versión de excel,ya que tengamos todo seleccionado damos clic en siguinete  

Fig.5 Definicion de la copia

Esta venta solo nos indica que si al realizar la copia desde una consulta o escribir una sentencia sql para lo cual dejaremos la que esta seleccionada por default y damos clic en siguiente.

Fig.6 Delegación de datos 

En esta pantalla lo que tendremos a derecha sera las hojas de nuestro libro de excel y a la izquierda la tabla
en la que se guardaran los datos de nuestra primera hoja de excel si quisiéramos ver un detalle de como se ven los datos de la hoja de excel en nuestra tabla solo tendremos que dar clic en vista previa.

Fig.7 Vista Previa de Datos

La información que tenemos ya en hojas de calculo de excel se ve de esta manera en nuestra tabla creada en  la base de datos.

Por ultimo damos aceptar y Finzalizar el proceso de importar los datos del excel a nuestra tabla creada en la base de datos ,esta nos dará un informe sobre la importación de los datos o posibles errores que puedan surgir durante el proceso como se muestra en la siguiente imagen

Fig.8 Informe del proceso de importación de datos

Una vez terminado damos click en  cerrar y para confirmar que los datos de nuestro excel este ya en nuestra tabla , solo tenemos que ejecutar una consulta 

select Nombre,Clave from TEntidadesFederativas

Una vez realizada la consulta  esta no debe de mostrar los datos que hemos importado de nuestra hoja de excel a nuestra tabla creada en la base de datos como se muestra en la siguiente imagen,

Fig.9 Resultados de la consulta SQL

Saludos...

Administar objetos en Sql Server

A quien no le a pasado durante el  desarrollo del software  ,en la parte de base de datos llega un momento en que esta tanta la información que se almacenara y  empezamos a crear tablas,procedimientos almacenados,vistas,triggers,llaves primarias y foreanes pero al  final no sabemos que hemos creado o la cantidad exacta que existe de cada uno de  lo ya mencionado.

Bueno en esta entrada les dejare algunas consultas que puedes realizar en el manejador  de base de datos para tener una mejor administración en la creación de los objetos ya mencionados.

Cabe mencionar que para ejecutar la mayoría de las consultas es necesario contar con un usuario con la mayoría de los permisos en el manejar de la base de datos.

Fig1 Datos de Inicio de Session

Aquí las consultas para administrar los objetos creados en la base de datos.

--Consulta te permite ver las bases de datos dadas de alta en el manejador 
--de base de datos. 
select name from master.dbo.sysdatabases


--Consulta para mostrar todas las tablas creadas .
select name from sysobjects where type='U'


--Consulta para mostrar todas las vistas creadas .
select name from sysobjects where type='V'


--Consulta para mostrar los procedimientos almacenados creados
select name from sysobjects where type='P'


--Consulta para mostrar todas las llaves primarias creadas 
select name from sysobjects where type='K'


--Consulta para mostrar todas las llaves foraneas creadas 
select name from sysobjects where type='F'

Bueno pues son algunas consultas que debemos tener encuenta durante el desarrollo del software y despues de , si quieres ver mas información  de la consulta solo basta con cambiar "name" por  el  caracter "*"

Saludos...

Documental sobre Ciberguerra

Hace tiempo que la tecnología  a revolucionado al mundo y que da vez están mas presentes en nuestra vida y que han tenido un gran impacto dentro de la sociedad .

Alguna vez te has preguntado cual es el papel que juegan las nuevas tecnologías en nuestro entorno e aqui un documental sobre ciberguerra.

En portada - Amenaza Cyber

Un documental que tarata de explicar lo que ocurre en nuestro entorno espero y se  ha de su agrado 

Saludos..

Un motivo de cambio / SOLID

Siempre he pensado que el cambio no es tan malo, pero depende... es en esos momentos en que uno acude a la red: ¿El cambio es bueno o malo? ... el caso es que en ocasiones es mejor estar preparado.

Del mismo modo cambian los requerimientos y no siempre es tan sencillo solventar situaciones si no se realiza un buen diseño y una buena estructura.  Mi amigo de kinder garden  Robert C. Martin, quién publicó 5 principios básicos dentro de Principios de Diseño y Patrones de Diseño, nos dejó una manera de hacer amena esta situación.

No es un estándar y tampoco hay algo que nos obligue a diseñar nuestros programas bajo estos principios, sin embargo, el seguirlos o apegarnos lo más posible, nos llevará a un diseño fácil de mantener,  escalar, más legible, más organizado y por consecuencia de mejor calidad.

Principio de Única Responsabilidad (Single Responsibility Principle)

La primera letra del acrónimo -o mejor dicho acrónimo de acrónimos- SOLID (S: Single Responsibility Principle), es el primer principio descrito por mi amigo. Éste principio establece que una clase debe tener una única responsabilidad -un motivo por el cual existe esa clase- en el sentido de que solo debe de haber una razón por la cuál deba ser modificada, es decir, un solo motivo de cambio.

Si una clase tiene dos o más responsabilidades, es decir, se encarga de tareas que refieren a contextos diferentes, necesariamente llegada la necesidad de cambio asumirá más de un motivo por el cual pueda ser modificada y esto afectará a tareas que no tienen que ver con el origen de dicha clase.

Para no menear tanto "bla bla bla" entremos al detalle ;) ...  Les debo el ejemplo ;)

REST vs SOAP

Primero se debe tener claro que es cada cosa... escuchando alguna plática de gurús BPM con tu abuela, me di cuenta que hay cosas que creo están mal interpretadas, pero bueno me ha pasado nos pasa a todos.

No hay problema... el caso es que en ocasiones los términos pueden llegar a confundir y hacer que tomemos una opción inadecuada frente a x situación.

No me hagas pensar!

SOA (Service Oriented Architecture) es un concepto que refiere a un tipo particular de paradigma de arquitecturas de software.

Permite la creación de una arquitectura que se integra -o forma parte- de sistemas de información y/o aplicaciones que pueden llegar a ser bastante escalables, que permiten modelar todo el proceso de negocio de alguna organización, además es capaz de exponer e invocar servicios web, lo cual lleva a tener una rápida, práctica y, en general, una fácil integración de nuestra información. 

Para hacer analogía, la POO trabaja sobre aplicaciones construidas bajo un conjunto de librerías de clases -como podría ser un Framework-. Por el contrario, SOA se centra en sistemas que se construyen basándose en un conjunto de servicios independientes y autónomos.

¿Y con que se come ?

REST (Representational State Transfer) y SOAP (Simple Object Access Protocol) es como comparar peras y manzanas. Sin embargo, representan dos tipos diferentes -muy diferentes- para la implementación de una arquitectura SOA.

REST es un patrón de arquitectura construido bajo verbos simples que se adaptan bastante fácil con HTTP.

A diferencia, SOAP es un protocolo de mensajería basado en XML (mensajes SOAP con una estructura XML) que puede utilizarse por una variedad de protocolos de transporte, incluso el mismo HTTP.

¿Porqué son diferentes?

La principal diferencia entre el patrón REST y el protocolo SOAP, es la forma en la que se mantienen los diferentes estados por los que una aplicación pasa durante su vida. 

Con SOAP, el movimiento por los diferentes estados se realiza interactuando con un extremo único del servicio que puede encapsular y proporcionar acceso a muchas operaciones y tipos de mensaje. Por el contrario, con REST, se permite un número limitado de operaciones y dichas operaciones se aplican a recursos representados y direccionados por direcciones HTTP (URI). Los mensajes capturan el estado actual o el requerido del recurso. Por consecuencia, REST se integra bastante bien con aplicaciones Web donde se puede hacer uso de HTTP para tipos de datos que no son XML (o que no pueden serlo).

REST

1.- La arquitectura encaja de manera natural con HTTP.

2.- Necesario para clientes donde la capacidad es muy limitada (Escenarios JavaScript)

3.- No hay necesidad de Proxys (como en SOAP) para las conversiones y demás.

4.- Trata con acceso a recursos

REST - SOAP

5.- Operaciones remotas (una de las finalidades de los servicios web)

6.- Acceso a recursos remotos (más de lo anterior)

7.- Interoperable (otra de las finalidades de los servicios web)

SOAP

8.- El cifrado es a nivel de mensaje

9.- Dispone de ruteadores o intermediarios

10.- Reeegularmente (no creo que siempre) el envío de mensajes es confiable.

11.- Políticas de control (Diferentes perfiles)

12.- Basado en acciones

En resumen:

Ventajas de REST

• Está totalmente bajo especificaciones del protocolo HTTP, en donde todo actúa como un recurso, ni siquiera los servicios se escapan, se trata el mensaje igual como si fuera alguna imagen, uno o varios elementos HTML, etc. 
• No es tan estricto como SOAP, los datos pueden mantenerse estrictamente o de forma desacoplada, mediante la URI.
• Los recursos pueden consumirse fácilmente desde JavaScript (La mayoría de las aplicaciones que utilizan OpenId o el protocolo OAuth utilizan JavaScript para realizar llamadas con REST, por ejemplo twitter)
• Los mensajes son bastante ligeros, el rendimiento y la escalabilidad no deberían ser problema y cuando uno está acostumbrado a trabajar en "Internet", esto es de vida o muerte.
• REST no se queja, puede utilizar XML o JSON para el formato de los datos.

Desventajas de REST

• Si se trata de trabajar con objetos fuertemente tipados, tipo =P, en el código de servidor, es algo tedioso incluso difícil, pero esto también depende de otras situaciones.
• No creo (no lo sé) que funcione bien con aplicaciones de alto rendimiento y basadas en tiempo real. Por ejemplo, algún sistema para ingeniería industrial que arroje constantemente datos y mas datos para generar estadísticas.

Ventajas de SOAP

• Trabaja bien con datos, los mensajes y las comunicaciones están bien estructurados.
• Dispone de proxys fuertemente tipados.
• Funciona sobre diferentes protocolos, no solamente HTTP (como en REST) si no también sobre TCP, NamedPipes, MSMQ, etc. aunque el uso de estos no es tan bueno si se trata de estandarizar en Internet.

Desventajas de SOAP

• Los mensajes generados por SOAP no se pueden cachear (¿o si?)
• En JavaScript.. olvídate de SOAP.

¿Y entonces cuál?

No sé.. depende..

SOAP se ajusta muy bien para arquitecturas SOA implementadas dentro de aplicaciones con arquitecturas N-Layer. Además, SOAP gestiona aspectos de seguridad y direccionamiento mediante su implementación interna. También, funciona mucho mejor que REST con otro tipo de protocolos. Aunque, como comentaba, pierde "estandarización" pero si se trata dentro de una intranet donde los sistemas están controlados, creo que SOAP es la mejor opción.

Por el contrario, REST es normalmente mas adecuada para servicios distribuidos públicamente en Internet o en casos donde los consumidores son desconocidos (como el caso de implementaciones de OAuth).

REST es stateless por su naturaleza (HTTP), esto significa que cada petición individual enviada desde el cliente al servidor debe contener toda la información necesaria para entender la petición puesto que el servidor no almacenará datos de estado de sesión, o alguna mierd* cosa similar.

En definitiva, ambos protocolos permiten intercambiar datos haciendo uso de verbos y cada uno tiene sus desventajas frente al rendimiento y al ser escalables...

Al final, cada quien lo que se le antoje =P

FindControl en Asp.Net

Bueno pues después de varios intentos de poder asignarle un valor a un control  desde una MasterPage estuve investigando y llegue a poder hacerlo con el metodo FindControl de la clase System.Web.UI .

Básicamente lo que hace el método es buscar el control de servidor en el contenedor de nomenclatura actual con el parámetro especificado del id.

Cuando creamos controles en este caso asp.net todos por defecto deben de llevar un id.

Entonces el problema era que necesitaba asignarle un valor a un control de tipo TextBox pero el control no pertenecia a la  MasterPage sino  que era un control de una pagina que usaba la MasterPage para ello hice lo sigiuente :

 protected void Page_Load(object sender, EventArgs e)
    {
        //Buscando el control con ayuda del metodo FindControl
        Control txtMiControl = (TextBox)this.Page.Master.FindControl("MainContent").FindControl("txtNombre");

        //Validar que exista el control
        if (txtMiControl != null)
        {
            ((TextBox)txtMiControl).Text = "Hola Mundo";
        }
        else
        {
            
            //Enviar un mensaje de que el control no existe 

            this.lblMensaje.Text = "Control no encontrado.";
        }
    }

La estructura como tenia el control es la siguiente :

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="wfrmDemo.aspx.cs" Inherits="wfrmDemo" %>




    

Al final es cuestión de saber identificar que id usa tu control y donde esta situado , permitiéndote agregar  o modificar los valores de sus propiedades.

Saludos...