Tutorial de ASP.

NET MVC
Que es ASP.NET
ASP.NET es el conjunto de tecnologas de desarrollo web de Microsoft basada en la plataforma .NET, que nos permitir la creacin de sitios web y aplicaciones. ASP.NET nace en el ao 2002, y promete ser una autentica revolucin dentro del desarrollo web. Inicialmente solo presenta los formularios web Web Forms - , cuyo principal objetivo es acercar el paradigma de desarrollo rpido de aplicaciones (RAD) a la web. Rpidamente se amplia para dar capacidad a otros modelos de desarrollo, hasta que en el momento actual disponemos de los siguientes:

ASP.NET Web Forms Desarrollo RAD de aplicaciones web. http://www.asp.net/web-forms Web Pages Desarrollo simple de pginas web. http://www.asp.net/web-pages ASP.NET MVC. Aplicacin del patrn MVC. http://www.asp.net/mvc Para poder seguir este tutorial necesitaremos ciertos conocimientos de programacin, en particular de la plataforma de desarrollo .NET y del lenguaje C# en particular. Podemos acceder a completos tutoriales desde los siguientes enlaces:

Introduccin a la plataforma .NET, http://www.devjoker.com/contenidos/programacion/25/Introduccion-a-NET.aspx Conceptos generales de .NET, http://www.devjoker.com/gru/Conceptos-generales-NET/INET/Conceptos-generalesNET.aspx

Tutorial de C#, http://www.devjoker.com/gru/TutorialCSharp/TUCS/C.aspx

mbito y propsito de este tutorial

Este tutorial pretende ser una gua de desarrollo web, centrada en ASP.NET MVC. Partiremos desde los conceptos bsicos de desarrollo web HTTP, HTML y CSS, para ir profundizando en ASP.NET MVC. Como siempre, el enfoque que se dar al tutorial ser principalmente practico, presentando con lo conceptos tcnicos acompaados de numerosos ejemplos.

Herramientas necesarias para la realizacin de este tutorial.

Microsoft proporciona de forma de gratuita todas las herramientas necesarias para el desarrollo web con ASP.NET. En concreto necesitamos instalar en nuestro equipo las siguientes herramientas:

Microsoft Visual Studio Disponemos de una versin completamente gratuita en esta direccin http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-web-developer-express

Aunque Visual Studio dispone de un servidor web de desarrollo (conocido como Casini), recomendamos la instalacin de IIS Express:

IIS Express El servidor de aplicaciones web de Microsoft. Nuevamente disponemos de una versin gratuita :http://www.microsoft.com/es-es/download/details.aspx?id=1038 Por ltimo, vamos a necesitar una base de datos SQL Server. Esta se instala automticamente con Visual Studio, pero recomendamos actualizar a la ltima versin:

SQL Server Express: http://www.microsoft.com/sqlserver/en/us/editions/2012-editions/express.aspx

Fundamentos de funcionamiento de una aplicacin web

Arquitectura cliente-servidor y modelo de peticin - respuesta
Antes de poder entrar a ver como se programa una aplicacin con ASP.NET es necesario conocer algunos de los fundamentos de funcionamiento de una aplicacin web. Los primero que debemos saber es que las aplicaciones web se basan en una arquitectura cliente-servidor. Donde:

El servidor es el ordenador encargado de proporcionar el contenido. Para ello necesitamos instalar un servidor web en dicha mquina. Existen multitud de servidores web (Apache, LigHTTPd, IIS) pero no todos son capaces de ejecutar aplicaciones ASP.NET. nicamente los servidores de Microsoft pueden desempear dicha tarea. En nuestro caso utilizaremos IIS Espress. El cliente, que es el encargado de solicitar la informacin al servidor y mostrarla al usuario. Es el navegador (Interner Explorer, Firefox, Chrome, etc ). Si estas viendo est pagina estas utilizando un navegador web. El funcionamiento de una aplicacin es simple, el cliente emite una peticin de un recurso que se encuentra en el servidor, y el servidor devuelve el recurso solicitado que es mostrado por el navegador.

La peticin del recurso en concreto se realiza a travs de una URL. Una URL no es mas que una cadena de texto, expresada en un formato determinado en la que indicamos el protocolo, el puerto, el servidor y el recurso que estamos solicitando. Por ejemplo:
http://www.devjoker.com:80/default.aspx

En nuestro caso el protocolo es HTTP, el servidor www.devjoker.com, el puerto el 80 y el recurso default.aspx. El puerto estndar para el protocolo HTTP es el 80, por lo que no se suele especificar. Dependiendo de la configuracin del servidor podramos omitir el recurso y asignar uno por defecto. De este modo la siguiente URL seria equivalente a esta otra:
http://www.devjoker.com

La peticin HTTP tendra la siguiente forma:

GET http://www.devjoker.com/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding: gzip, deflate Host: www.devjoker.com If-Modified-Since: Fri, 03 Aug 2012 10:57:59 GMT Connection: Keep-Alive Pragma: no-cache Cookie: ASP.NET_SessionId=nullimt1wzjmbtik5ferit4w;
Aunque nosotros solo especifiquemos la URL, el navegador web aadir cierta informacin adicional a la peticin como el tipo de contenido que acepta como respuesta, el lenguaje, tipo de navegador

Y la respuesta sera algo similar a esto (se acorta el contenido del documento HTML devuelto por razones de espacio):

HTTP/1.1 200 OK Cache-Control: public Content-Type: text/html; charset=utf-8 Expires: Fri, 03 Aug 2012 10:58:48 GMT Last-Modified: Fri, 03 Aug 2012 10:58:38 GMT Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Fri, 03 Aug 2012 10:58:39 GMT Content-Length: 42013
<!DOCTYPE html > <html lang="es"> <head id="Head1"> <title>www.devjoker.com</title> </head> <body> <!-- Contenido de la pgina!!!! --> .... </body> </html> Tanto la peticin como la respuesta pueden tener dos secciones diferenciadas: Las cabeceras de HTTP (indicadas en cursiva y color gris en el ejemplo) y el cuerpo. Profundizaremos algo ms en estos conceptos en captulos posteriores de este tutorial. De momento diremos que en el caso de la peticin HTTP podemos enviar informacin adicional (normalmente los datos de un formulario web), y que en el caso de la respuesta HTTP recibiremos el contenido HTML, el lenguaje de marcado que utilizar el navegador para visualizar la pgina. Afortunadamente ASP.NET (y todos los framework de desarrollo web) encapsulan el manejo de la solicitud y la respuesta en objetos de fcil acceso.

Servidores DNS
Falta an por introducir un elemento importante. Los servidores en internet (en realidad cualquier ordenador dentro de una red) se identifica por una direccion IP. Sin embargo, en el ejemplo anterior, al proporcionar la URL, no nos hemos referido a una direccin IP, sino al nombre del servidor (mas concretamente al nombre de dominio). Entonces Como sabe el navegador que un determinado servidor www.devjoker.com se corresponde con una direccin IP concreta? La respuesta es simple: Los servidores DNS. Un servidor DNS es una especie de centralita de internet, de forma que cuando un navegador solicita una URL a un servidor desconocido, primero se consulta la centralita para obtener la direccin IP. Por motivos de rendimiento, una vez que se ha resuelto el nombre de dominio se almacena localmente para que no sea necesario volver a preguntar.

Podemos realizar consultas directamente al servidor DNS con la aplicacin nslookup: Microsoft Windows [Versin 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Reservados todos los derechos. C:\Users\pedro_herrarte>nslookup Servidor predeterminado: google-public-dns-a.google.com Address: 8.8.8.8 > devjoker.com Servidor: google-public-dns-a.google.com Address: 8.8.8.8 Respuesta no autoritativa: Nombre: devjoker.com Address: 188.165.132.77 > 188.165.132.77 En el ejemplo anterior estamos utilizando los servidores DNS de Google (IP 8.8.8.8). Por ultimo, nos faltara conocer como es capaz el servidor DNS de obtener la IP correcta de nuestro servidor www.devjoker.com. Cuando registramos un dominio en internet, debemos configurar dicha informacin a travs del panel de control DNS (opcin que proveen TODOS los registradores de dominio TODOS? NO! MoviStar no te permite configurar los registros de DNS y te obliga a contratarlo como servicio aparte. Mi recomendacin es que NUNCA registris un dominio con MoviStar). De este modo, publicamos que nuestro nombre de dominio devjoker.com, se corresponde un servidor (o conjunto de servidores) con una direccin IP concreta. La siguiente imagen muestra la configuracin DNS de devjoker.com:

De un modo similar funciona el envo de correos electrnicos, con las salvedad de que el servidor DNS es consultado para registros de tipo MX Mail eXchange, es decir, que para que nuestro servidor sea capaz de enviar y recibir correos debemos haber configurado correctamente ambos servidores y haber configurado los servidores DNS adecuadamente.

Protocolo HTTP
El protocolo de comunicaciones que se utiliza para solicitar y recibir pginas web es HTTP. HTTP es el acrnimo de HyperText Transfer Protocol, siendo el aspecto mas relevante que se trata de un protocolo de transmisin de texto. Solo texto. Es sumamente importante entender este aspecto, ya que condiciona como funciona la web. Si analizamos los elementos base en los que sostiene la web hoy en da, nos encontramos los siguientes elementos fundamentales:

El lenguaje para la definicin de los elementos de una pgina y su contenido es texto HTML. Veremos una pequea introduccin a HTML en el siguiente capitulo. El lenguaje para la definicin del aspecto visual de la pgina es texto. CSS. Tambin veremos una introduccin a CSS en este tutorial. El lenguaje para la programacin del lado del cliente JavaScript, que se recibe en cuerpo de la respuesta como texto, y se compila e interpreta en el cliente. (Esto tiene interesantes matices, como la posibilidad de escribir cdigo dinmicamente en el servidor ) HTTP es un protocolo sin estado, es decir, HTTP no guarda ninguna informacin sobre conexiones anteriores. Esto significa que cuando enviamos varias solicitudes HTTP, la solicitud actual no conoce en los datos que han enviado y recibido las peticiones anteriores. Por ejemplo, si en una primera solicitud enviamos la informacin de un usuario, y luego visitamos una segunda pgina, esta segunda pgina no sabe que usuario utilizamos en la anterior. Este es un factor que condiciona completamente la forma de trabajar cuando desarrollamos aplicaciones web, ya que al no proporcionarnos esta informacin el protocolo vamos a tener que realizarlo a nivel de aplicacin. Adems las peticiones HTTP responden a una serie de verbos predefinidos, segn el verbo de la solicitud el servidor actuar de una forma u otra. Los verbos mas comunes son GET y POST, aunque existen mas. Veremos mas adelante que ASP.NET MVC permite especificar que un mtodo de un controlador responda nicamente a un conjunto de verbos concretos. Cuando veamos la parte dedicada a AJAX y jQuery veremos que existen mtodos $.get() y $.post() para realizar peticiones utilizando uno u otro verbo de forma simple desde JavaScript.

Ha continuacin vamos a ver un par de ejemplos sobre GET y POST. GET Solicita un recurso especifico. Se utiliza sobre todo cuando solicitamos un recurso sin necesidad de enviar informacin adicional, aunque el verbo GET permite enviar datos adicionales como parte de la URL solicitada, su uso debe realizarse con cuidado, ya que es una informacin que un usuario malintencionado podra modificar para realizar un ataque.

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

POST Enva los datos incluyndolos en el cuerpo de la peticin. Es muy habitual para el envo de datos (a travs de formularios), en los que el usuario rellena cierta informacin y la enva al servidor. POST http://devjoker.com/login.aspx HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate Host: devjoker.com Content-Length: 650 Connection: Keep-Alive Pragma: no-cache UserName=nombreUsuario&Password=laclave El ejemplo anterior corresponde a la captura de una peticin HTTP de un formulario de identificacin de usuario a travs de POST. Podemos ver que la informacin se enva en el cuerpo de la peticin, y fcilmente podemos obtener el usuario y el password, siendo muy fciles de capturar (al menos desde el propio equipo que realiza las peticiones!). Es por este motivo, por el existe una versin cifrada de HTTP HTTPS , que se encarga de cifrar todas comunicaciones que se producen entre el navegador y el servidor. Es un aspecto que tendremos que tener en cuenta siempre que nuestras aplicaciones requieran del manejo de datos sensibles. Por ltimo, comentar que HTTP responde a cada peticin con un cdigo de estado predefinido que permite al navegador identificar que accin debe realizar. A continuacin vamos a ver algunos de los cdigos HTTP mas comunes.

Cdigos de estado HTTP.

Cada respuesta HTTP identifica el resultado de la peticin a travs de un cdigo HTTP. Dependiendo de este cdigo de respuesta de HTTP el navegador realizar una accin u otra. Por ejemplo, mostrar la pantalla

solicitada si el estado es 200 (OK) o mostrar la pantalla de error en caso de que reciba un error 500 (error de servidor). Los cdigos de error de HTTP con cdigos numricos, agrupados en familias por centenas. De forma que los errores 200 corresponden a peticiones correctas, los errores 300 redirecciones, los 400 errores en la peticin y los errores 500 errores de ejecucin del lado del servidor. De manera muy breve veremos los principales cdigos de respuesta de HTTP.

200 OK
Indica que el servidor a obtenido y enviado correctamente el recurso solicitado por la peticin. En este caso el cuerpo de la respuesta contendr el contenido en texto (HTML, CSS, Javascript, etc) del recurso solicitado, permitiendo al navegador mostrarlo en la pantalla. El siguiente ejemplo muestra una peticin GET al recurso http://devjoker.com : GET http://devjoker.com/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding: gzip, deflate Host: devjoker.com If-Modified-Since: Sun, 19 Aug 2012 22:22:57 GMT Connection: Keep-Alive Y la respuesta obtenida: HTTP/1.1 200 OK Cache-Control: public, max-age=10 Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Expires: Sat, 22 Sep 2012 22:37:05 GMT Last-Modified: Sat, 22 Sep 2012 22:36:55 GMT Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Sat, 22 Sep 2012 22:36:56 GMT Content-Length: 9357 <html> </html> La respuesta incluye el cdigo HTML de la pgina que permitir al navegador mostrar el contenido solicitado. Por razones de espacio se omite el contenido HTML en este ejemplo.

301 Redireccin permanentemente.

sta es la opcin ms habitual en el caso de migraciones o cambios de dominio, indica al navegador que el recurso solicitado no ha cambiado de ubicacin y que debe solicitar una nueva URL. Adems le insta a modificar cualquier enlace que conserve almacenado o informacin asociada a dicha URL (como por ejemplo,

el ndice de Google o Bing). Una redireccin 301 es interpretada por los motores de bsqueda de forma que implica que toda la informacin asociados a la pgina original se transmitan a la de destino , por lo que es el ms aconsejable para trasladar contenido.

302 Found.
Indica que un recurso ha sido localizado pero que no ha sido devuelto como parte de la respuesta, indicando una nueva localizacin para el recurso. Est es la opcin que se utiliza cuando queremos efectuar la redireccin de un recurso a otro diferente. El cdigo 302se suele usar para todos los traslados temporales, donde el servidor responde al navegador indicndole una nueva URL con el nuevo recurso. Es el navegador el que interpreta este cdigo y realiza una nueva peticin (esta vez al nuevo recurso). El siguiente ejemplo muestra una respuesta HTTP 302 en la que navegador redirecciona a un nuevo recurso (Location: /private/index.aspx) HTTP/1.1 302 Found Cache-Control: private, no-cache="Set-Cookie" Content-Type: text/html; charset=utf-8 Location: /private/index.aspx Tambin Es muy comn utilizar el cdigo 302 para controlar la navegacin dentro de un sitio web.

304 Not Modified.

Bsicamente indica que el contenido no se ha modificado desde la ltima vez que se solicit. Lo mas normal es que nunca se provoque este estado a propsito, sino que dejemos al servidor decida cuando usarlo. La consecuencia directa en que cuando un navegador recibe est cdigo, la respuesta no contiene contenido alguno es el cuerpo el recurso se obtendr del los archivos temporales almacenados por el navegador en peticiones anteriores. Por ejemplo, si una pgina no se ha modificado, no se transmite de nuevo el contenido de la misma, simplemente se indica que no se ha modificado a travs del cdigo 304 y el navegador utiliza la ltima versin de la que dispone. HTTP/1.1 304 Not Modified Last-Modified: Mon, 06 Aug 2012 17:12:08 GMT Accept-Ranges: bytes ETag: "35ec559cf673cd1:0" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Sat, 22 Sep 2012 22:36:58 GMT Podemos entender mejor este cdigo de estado si pensamos en una imagen que se muestra en una pgina web, la primera vez que visitamos la pgina el servidor nos entrega la imagen, pero en peticiones sucesivas se detecta que la imagen no se ha modificado y se utiliza la versin que se descargo la ultima vez.

400 Bad Request.

Este cdigo indica que la solicitud no est correctamente formada. Normalmente se produce este error cuando la URL no es correcta. HTTP/1.1 400 Bad Request Otros errores de la familia 400 son:

401 No autorizado 402 Pago requerido 403 Prohibido

404 Not Found.

Sin lugar a dudas el error mas comn. Indica que a pesar de que la peticin es correcta el recurso solicitado no existe en el servidor. Normalmente esto se produce debido a que la URL apunta a un recurso que no existe en el servidor, pero tambin es posible que el servidor este ocultando el recurso intencionadamente. HTTP/1.1 404 Not Found Content-Type: text/html Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Sat, 22 Sep 2012 22:51:04 GMT Content-Length: 1245 Tambin se puede producir un error 404 cuando el servidor no tiene configurado el tipo de recurso correctamente.

405 Method Not Allowed.

Este cdigo indica que el verbo utilizado en la peticin no es vlido. Se incluye como parte de la respuesta los verbos admitidos por el recurso. HTTP/1.1 405 Method Not Allowed Allow: GET, HEAD, OPTIONS, TRACE Content-Type: text/html

500 Server Error

La familia de errores 500 corresponden con errores de servidor. Se pueden deber a multitud de causas, ya que suelen corresponder con un error de nuestra aplicacin. Por ejemplo, si en nuestro programa cometemos un error de programacin e intentamos realizar una divisin por cero, el cliente recibir un error 500 como resultado de la respuesta.

Tambin se produce un error 500 cuando el servidor no dispone de los recursos necesarios para atender la peticin. El siguiente ejemplo muestra un ejemplo de peticin a devjoker.com en el que hemos detenido intencionadamente la aplicacin. En este caso obtenemos un error con cdigo 503 que nos indica que la aplicacin no est disponible 503 Service Unavaileable. GET http://devjoker.com/ HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: es-ES User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding: gzip, deflate Host: devjoker.com Connection: Keep-Alive ----------------------------------------------------------------------------------------------------------------------------------HTTP/1.1 503 Service Unavailable Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date: Sat, 06 Oct 2012 15:41:03 GMT Connection: close Content-Length: 326 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"> <HTML><HEAD><TITLE>Service Unavailable</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Service Unavailable</h2> <hr><p>HTTP Error 503. The service is unavailable.</p> </BODY></HTML> Los errores 500 definidos son: 501 No implementado, 502 Pasarela incorrecta, 503 Servicio no disponible, 504 Tiempo de espera de la pasarela agotado y 505 version not suported.

505 HTTP Version Not Supported.

Este error se produce cuando la peticin solicita una versin de HTTP no soportada por el servidor. El siguiente ejemplo muestra una peticin HTTP 2.0, y el error devuelto indicando que el servidor no soporta esta versin de HTTP. GET http://www.devjoker.com/ HTTP/2.0 Host: www.devjoker.com ------------------------------------------------------------------HTTP/1.1 505 HTTP Version Not Supported Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Un estudio mas detallado del HTTP escapa completamente del mbito de este tutorial donde solo pretendemos dar una breve introduccin para facilitar los conceptos de programacin con ASP.NET MVC que veremos en captulos posteriores.

Analizar el trafico HTTP.

Si queremos analizar el trfico HTTP directamente podemos hacerlo directamente utilizando las herramientas de desarrollo que incorporan casi todos los navegadores (pulsando F12), o bien a travs de herramientas especificas como Fiddler. La siguiente imagen muestra Fiddler utilizado para capturar el trfico.

Solution Load Manager. Extension de Visual Studio para trabajar con soluciones de gran tamao.
Cuando trabajamos en Visual Studio con Soluciones de gran tamao, lo mas habitual es que solo trabajemos al mismo tiempo con un pequeo nmero de proyectos, por lo que cargar y compilar todos los proyectos resulta una carga innecesaria. Especialmente cuando trabajamos varios equipos, en una arquitectura bien estructurada en capas es muy habitual que existan especialistas web que solo trabajen con presentacin, arquitectos que se ocupen de la infraestructura No obstante, cuando abrimos la solucion Visual Studio carga todos los proyectos (aunque no los vayamos a necesitar) y hace que nuestro trabajo sea mucho mas lento de lo que debera, y por lo tanto seamos mucho menos productivos.

Solution Load Manager es un excelente pluging de Visual Studio que nos va a permitir especificar que proyectos queremos cargar cuando abramos la solucion de Visual Studio. Adems disponemos de la posibilidad de crear perfiles, de modo que podemos especificar facilmente que proyectos han de cargase en cada momento.

Podemos descargar Solution Load Manager desde este enlace. Una vez instalado se habita una nueva opcin de men contextual (boton derecho) de la solucin.

Este men nos permitir acceder a la pantalla de configuracin de Solution Load Manager, desde donde podremos especificar que proyectos se deben cargar al abrir la solucion

Simplemente marcando los proyectos y utilizando los botones de color de la parte superior de la interfaz podemos especificar cmo han de cargarse los proyectos al abrir la solucin. La opciones permitidas son:

Cargar el proyecto por defecto al abrir la Solucin. Carga en segundo plano. Cargar el proyecto si es necesario. Carga explicita. Una vez realizadas las modificaciones, recargaremos la solucin con solo los proyectos necesarios para nuestro trabajo. Espero que os sea de tanto utilidad como me ha sido a m.

Reducir el tamao del log de transacciones en SQL server

Una pregunta tpica en servidores SQL que usan el modo de restauracin FULL o BULK es cmo reducir el tamao del log de transacciones cuando este crece de forma anormal en SQL server 2008 o superior.

Normalmente el log se reduce slo cuando hacemos un backup pero hay ocasiones en que esto no es as y el log crece y crece .

Para evitarlo y reducir de nuevo el log tenemos que ejecutar el siguiente script: -usamos la base de datos ficticia devjoker2013BD --Primero hacemos un backup completo de la base de datos para evitar perder la informacin del log --en caso de restauracin hasta un punto en el tiempo BACKUP DATABASE devjoker2013BD TO DISK = 'D:\SQLServerBackups\devjoker2013BD.Bak' WITH FORMAT, MEDIANAME = 'D_SQLServerBackups', NAME = 'Backup completo de devjoker2013BD previo al truncado del log'; GO --cambiamos el modo del log de base de datos a SIMPLEALTER DATABASE devjoker2013BD SET RECOVERY SIMPLE; GO -- Comprimimos el log a un slo MB de tamao DBCC SHRINKFILE (devjoker2013BD_Log, 1); GO -- Volvemos a dejar el log en modo completo (o bulk logged si ese era el caso). ALTER DATABASE devjoker2013BD SET RECOVERY FULL; GO

Nota: para que esta operacin funcione al 100% es posible que tengamos que dejar temporalmente la base de datos en modo monousuario (es decir sin acceso al mismo) para garantizar que no haya transacciones pendientes en el momento de hacer el truncado

En ese caso necesitaramos un cdigo como este: USE devjoker2013BD;

GO

ALTER DATABASE AdventureWorks2012 SET SINGLE_USER WITH ROLLBACK IMMEDIATE; GO ALTER DATABASE AdventureWorks2012 SET READ_ONLY; --Realizamos el backup y el truncado del log GO ALTER DATABASE AdventureWorks2012 SET MULTI_USER; Contrariamente a lo que podamos pensar a corto plazo no notaremos una mejora del rendimiento sino un empeoramiento ya que tarde o temprano el log volver a crecer hasta su tamao optimo que supuestamente ser menor que el tamao anterior pero mayor de 1MB que es el valor que especificamos anteriormente.

Una vez que el log tenga el tamao optimo y no sobredimensionado si deberamos notar una mejora del rendimiento aunque no siempre ser perceptible a simple vista. Por esto ltimo no deberamos realizar esta operacin como parte de un plan de mantenimiento sino cmo una operacin puntual cuando detectemos que el tamao del log toma un tamao exagerado y siempre despus de un backup completo para evitar perdida de datos en caso de tener que restaurar.

Como montar un entorno de sharepoint 2010 de forma simplificada (desarrollo y sistemas)

Un enlace interesante para poder montar una mquina de sharepoint de forma simplificada.
http://www.microsoft.com/en-us/download/details.aspx?id=23415

Es un script de power shell para facilitar toda la instalacin, funciona tanto en mquinas normales como en mquinas virtuales. Desgraciadamente slo est la versin para 2010 , todava no hay versin para 2013, tampoco incluye el visual Studio 2012 mucho ms para desarrollar en la versin 2012 pero en cualquier caso simplifica bastante la instalacin.