Acabo de publicar dos nuevos videos sobre las diversas herramientas que tenemos disponibles para administrar SQL Server, tanto para la versión 2000 como para las posteriores (2005 y 2008), algunas de ellas son: Enterprise Manager (2000), Query Analyzer (2000), Management Studio (2005, 2008 …), Profiler (menos conocida, pero imprescindible), etc…
Aquí os dejo el link, espero que os ayude a mejorar vuestra experiencia con el producto :)
Es habitual que se utilice Report Manager tanto para administrar Reporting Services, como para que los usuarios accedan a ejecutar sus informes. En muchas ocasiones nos piden que personalicemos la presentación que nos ofrece Report Manager, ya que nuestros clientes están habituados a que así sea en cualquier aplicación web.
No vamos a entrar en detalles de las posibilidades que tenemos para ello, pero sí que vamos a ofrecer una solución muy sencilla y que en ciertas ocasiones es suficiente, ésta consiste en sustituir el logo que aparece en la esquina superior derecha por el de la empresa en cuestión.
Básicamente consiste en sustituir una determinada imagen en una carpeta concreta. En el siguiente artículode Debin Knight tenéis una guía paso a paso de cómo hacerlo:
Change the Report Manager logo
Como veis, muy simple y útil, espero que os resulte útil :)
Una vez finalizado un proyecto de SQL Server Analysis Services, tenemos varias alternativas para desplegarlo, entre ellas hacerlo desde el propio Visual Studio. Es habitual que contemos con varios entornos, como desarrollo, pruebas, pre-producción, producción; o que simplemente tengamos un proyecto que queramos desplegar en diferentes servidores por cualquier otro motivo.
Una de las alternativas que tenemos, es utilizar el “Deployment Wizard”, que lo que hace es generar un script XMLA, para sea ejecutado posteriormente en el servidor de destino. Si os interesa conocer con detalle todo este proceso, os dejo un artículo publicado en SQLServerCentral en el que se explica paso a paso, e incluyendo todas las pantallas y explicaciones oportunas:
Poco a poco voy avanzando en la publicación del curso de administración de SQL Server orientado a desarrolladores, estos son los capítulos publicados hasta el momento:
Sé que algunos estáis impacientes por los mensajes que me habéis hecho llegar, pero hago lo que puedo, la producción de cada video lleva su tiempo, y no siempre puedo disponer de tiempo para estas tareas, pero todo se andará :)
Ya está disponible Report Builder 3.0 CTP November. Si ayer nos hacíamos eco de la aparición de la nueva CTP de SQL Server 2008 R2, hoy compartimos esta otra interesante noticia.
En esta ocasión está abierta a todo el mundo, os dejo el link: Microsoft Downloads, Report Builder 3.0 CTP November
Desde ayer está disponible la nueva CTP de noviembre de SQL Server 2008 R2, para suscriptores de MSDN y TechNet.
No dudéis en descargarla e ir conociendo de primera mano las interesantes novedades que aporta :)
Creo que a estas alturas todo desarrolladoR ha oído y leído que es una mala práctica utilizar la sintaxis SQL SELECT * FROM. Por un lado nos encontramos con que el gestor de bases de datos debe obtener de los metadatos cuáles son las columnas que debe devolver, que aunque no sea una gran penalización, también afecta al rendimiento. Por otro lado nos encontramos con que la adición de una nueva columna a una tabla puede suponer que dejen de funcionar muchas consultas e informes que no se ven afectados por dicho cambio, al recibir la aplicación más columnas de las esperadas.
Bien, pues todos admitimos que no es una buena práctica, pero la seguimos llevando a cabo. No paro de encontrar servidores donde se siguen ejecutando una gran cantidad de las instrucciones que usan el asterisco " * ". Unas veces por pereza, otras por hábito, otras por ... El caso es que ahí está esa mala práctica, tan admitida como utilizada.
Pues bien, es hora de ponernos firmes y evitar este uso, si de verdad estáis decididos a hacerlo, aquí os dejo un script que impide el uso de la sintaxis SQL del SELECT * FROM. Esto es posible gracias al uso de:
DENY SELECT ON OBJECT:: TuEsquema.TuTabla(DummyColumn) TO Usuario;
Tened en cuenta que restringe también el uso del count(*), pero eso tiene solución fácil podéis utilizar count(Columna), pero es importante que conozcáis los matices de una y otra variante y el resultado diferente que se puede obtener en caso de haber nulos, cosa que podéis solucionar utilizando una columna que sea primary key, y que por tanto no admitirá nulos :)
Os recomiendo que leáis con detalle el artículo Preventing usage of "SELECT * ...", y sobre todo que lo pongáis en práctica.
Es una práctica muy habitual que muchos usuarios tengan acceso a las tablas. En muchas ocasiones simplemente necesitan utilizar una aplicación, con la que deben gestionar y mantener datos. Otras veces son los propios desarrolladores que lanzan instrucciones INSERT, UPDATE o DELETE sobre ellas, asumiendo un alto riesgo sobre la integridad de los datos.
En muchos sitios hemos leído que es una buena práctica de seguridad que no se tenga acceso directo a las tablas y que sólo se de acceso a vistas y procedimientos almacenados. Mi recomendación va más a allá, y es dar sólo acceso a procedimiento almacenados (cuando sea posible).
El problema o las razones que me suelen argumentar es el trabajo que esto supone, pero no es así:
- La creación de los procedimientos almacenados para Insert, Update y Delete, se puede automatizar con los muchos generadores que hay, o haciendo el nuestro propio.
- Luego hay que gestionar la seguridad, y es una lata tener que ir dando permisos para que pueda ejecutar cada usuario todos los procedimientos almacenados de la aplicación. Por ejemplo si tenemos 50 tablas, habrá como mínimo 200 procedimientos almacenados, contando que por cada tabla haya sólo una Insert, una Update, una Delete y una Select, cosa que no es cierta, y este número sería mayor.
Además deberíamos tener ciertas reglas de negocio en los procedimientos almacenados, esto complica un poco más su creación, pero si no lo hacemos, tendremos un gran riesgo en cualquier actualización manual que tengamos que hacer sobre las tablas.
Bueno, ¿y por qué os cuento todo esto? pues porque una de las dos tareas que aparentemente son tediosas, la de dar permisos a cada usuario para que pueda ejecutar todos los procedimientos almacenados, es muy simple, podéis utilizar el procedimiento almacenado spGrantExectoAllStoredProcs, que podéis encontrar en MS SQL Tips (un excelente sitio, que os recomiendo seguir).
Espero que esto ayude a convenceros de poner en práctica las buenas prácticas comentadas anteriormente :-)
