Esecuele Sin Fronteras

SQL Server, Reporting Services y Biztalk Server
  • Esecuele Sin Fronteras

    Error: "Unable to load client print control" en Reporting Services

    • 10 Comments

     

    ¿Te has encontrado con el siguiente error últimamente al intentar imprimir un informe en Reporting Services?

     

    No se puede cargar el controlador de impresión

     (En Ingles: Unable to load client print control)

     

    Es muy seguro que este error haya sido producido por la instalación del siguiente aviso de seguridad: 956391, que actualiza killbits, una versión antigua del control RSClientPrint por una vulnerabilidad encontrada.

     

    Aviso de seguridad de Microsoft: Actualización de seguridad acumulativa para ActiveX

    http://support.microsoft.com/?id=956391

     

    Para solucionarlo, podéis instalar el último Cumulative Update 10 de SQL Server, que lo podéis conseguir del siguiente enlace:

     

    Cumulative update package 10 for SQL Server 2005 Service Pack 2

    http://support.microsoft.com/kb/956854/en-us

     

    Si utilizaseis el Report Viewer desde una aplicación web, CRM o SharePoint, os aconsejaría los siguientes pasos:

     

    1.     Primero verificar la versión del Report Server. Debería de ser 9.00.3073 or 9.00.3282.

    Si no, actualizar el Report Server:

    Security Update for SQL Server 2005 Service Pack 2 (KB954607)

    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5148b887-f323-4adb-9721-61e1c0cfd213

     

     

    2.     Ahora comprobar la versión del control ReportViewer (en caso de utilizarlo)

    Para ello, abrir el informe en la máquina cliente, hacer clic derecho en el informe y seleccionar “View Source”.

    Encontrar la siguiente línea:

     

    <script src="http://blogs.msdn.com/TestRSClientPrintReportViewer/Reserved.ReportViewerWebControl.axd?OpType=Resource&amp;Version=X.Y.ZZZZ

     

    3.     Ahora, Si el control es de tipo “Reserved.ReportViewerWebPart.axd” entonces tiene que ver con SharePoint.

    Hay un fix para esto en el siguiente enlace:

    Microsoft SQL Server 2005 Reporting Services Add-in for Microsoft SharePoint Technologies

    http://www.microsoft.com/downloads/details.aspx?FamilyID=1e53f882-0c16-4847-b331-132274ae8c84&displaylang=en

     

                   Si el control es de tipo “Reserved.ReportViewerWebControl.axd” vamos bien.

    Tenemos 2 versiones mayores diferentes: 8.00.50727 y 9.00.XXXX.

    Si ves la versión 8.00.50727 esto significa que está viendo informes desde CRM o utilizando el control ReportViewer desde una aplicación web.

    Si ves la versión 8.00.50727 y la versión es anterior a 8.00.50727.1843 entonces se debería de instalar el siguiente fix en el servidor ReportServer o en el servidor de CRM:

     

    Microsoft Report Viewer Redistributable 2005 Service Pack 1

    http://www.microsoft.com/downloads/details.aspx?familyid=82833F27-081D-4B72-83EF-2836360A904D&displaylang=en

     

    Si ves la versión  es 9.00.XXXX o 9.0.XXXX esto significa que está viendo informes desde Report Manager, Report Server o una aplicación web desde un Visual Studio VS 2008.

    En ese caso se tundra que instalar el siguiente fix en la máquina del report server:

     

    Microsoft Report Viewer 2008 SP1 Redistributable

    http://www.microsoft.com/downloads/details.aspx?FamilyID=bb196d5d-76c2-4a0e-9458-267d22b6aac6&DisplayLang=en

     

    Esto actualizará a la versión 9.0.30729.1 del control Report Viewer.

     

     

    Para Reporting Services 2000

     

    Hara falta instalar la siguiente actualización de seguridad en el servidor de Reporting Services

    Security Update for SQL Server Reporting Services 2000 Service Pack 2

    http://www.microsoft.com/downloads/details.aspx?familyid=5F9E7F78-7439-414B-A9DC-A779B89427DB&displaylang=en

     

    Y la siguiente version del Report Viewer redistributable en la máquina donde está la aplicación web (ó la máquina de CRM):

     

    Microsoft Report Viewer Redistributable 2005 Service Pack 1

    http://www.microsoft.com/downloads/details.aspx?familyid=82833F27-081D-4B72-83EF-2836360A904D

     

    La siguiente actualización de seguridad debería de estar instalada en todas las máquinas cliente:

    Microsoft Security Advisory: Update Rollup for ActiveX Kill Bits

    http://support.microsoft.com/kb/956391   

     

    He seguido los pasos arriba indicados y todavía me da el error al imprimir

     

    Si aun así os seguís encontrando el error al imprimir el informe desde vuestra aplicación. Pudiera ser que la versión del control rsClientPrint en las máquinas cliente no fuera igual a la versión del servidor.

    Una buena prueba sería que borraseis la el control que tenéis en la máquina cliente y permitáis que se descargue de nuevo desde el servidor. Esto se hace automáticamente al imprimir el informe, la primera vez que el control se va a utilizar o cuando la versión en el servidor cambia. Nótese que los usuarios necesitan tener permisos para descargar controles Active X.

    Los pasos a seguir en la máquina cliente serían:

    1.       Desregistrar RSClientPrint.dll en c:\windows\system32 folder

    2.       Borrar todos los ficheros RSClientPrint.dll y RSClientPrint*.rll del directorio

    c:\windows\system32 .

    3.       Ir a Windows\Downloaded Program Files y borrar la clase RSClientPrint 2005

    4.       Configurar la intranet de IE para que pida credenciales para descargar controles ActiveX

    5.       Ejecutar el informe y hacer clic en el botón de impresión.

    6.       Instalar el plugging ActiveX cuando lo pida

    7.       Confirmar que la clase RSClient 2005 se ha descargado  en Windows\Downloaded Program Files

    8.       Si os muestra un mensaje que empieze por “An error occurred during printing (0x80070006)”, habrá que reiniciar la maquina y repetir los pasos

     

    Una manera de comprobar la versión del control rsClientPrint en la máquina cliente sería (tiene que ser la misma versión que la del servidor)

    ·                      Abrir la ventana de comandos

    ·                      navegar a c:\windows\downloaded program files

    ·                      Copiar rsclientprint.dll a un directorio temporal, por ejemplo c:\temp

    ·                      Abrir el Explorador de Windows

    ·                      Navegar al directorio c:\temp

    ·                      En el menu contestual comprobar la versión

    ·                      Borrar RSClientPrint.dll del directorio temp

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

  • Esecuele Sin Fronteras

    Cómo crear una cuenta de inicio de sesión en SQL Server para una cuenta de máquina

    • 0 Comments

    Hoy queremos traer un escenario relacionado con la administración de cuentas de inicio de sesión que, aunque en apariencia es sencillo, puede generar algo de confusión y hacernos perder más tiempo del deseado.

    NOTA: Queda fuera de este artículo las consideraciones generales relativas a las mejores prácticas de seguridad para SQL Server 2005, 2008 y 2008R2. Tan sólo dejar claro que, como norma general y dentro de lo posible, en lo que se refiere a la creación de cuentas de inicio se recomienda el uso de la autentificación integrada con Windows y que, dentro de esta opción, se empleen grupos usuarios de dominio de tipo local (domain local group / local groups) en lugar de cuentas individuales (domain account / local account). Para más detalles sobre estos temas recomendamos consultar los enlaces de referencia incluidos al final del artículo.

    Escenario inicial

    En determinadas circunstancias puede existir la necesidad de dar permisos de acceso a una cuenta de máquina (computer account) en una o más base de datos dentro de una instancia de SQL Server. Para ello es necesario crear una cuenta de inicio de sesión para la cuenta de máquina y luego crear las cuentas de usuario en cada una de las bases de datos necesarias con los permisos adecuados. También es verdad que lo habitual es dar acceso una cuenta de usuario de dominio o a un grupo de usuarios local de dominio, o incluso crear una cuenta propia de SQL Server.

    Un caso donde es necesario crear inicio de sesión para cuentas de máquina puede ser que un producto “cerrado” (como SCOM 2007 por ejemplo) requiera este tipo de configuración, o que un desarrollo a medida (como un desarrollo en ASP.NET por ejemplo) se ejecute bajo el contexto de la cuenta de sistema “NT AUTHORITY\System” de forma local o “NT AUTHORITY\NETWORK SERVICE” si se está accediendo de forma remota.


    Imagen 1: Es posible ver cuentas de inicio de sesión de máquina en el explorador de objetos de SQL Server. Estas cuentas se identifican fácilmente porque con un símbolo de dólar “$” al final del nombre.


    Normalmente sólo es necesario preocuparse de la creación de inicios de sesión para este tipo de cuentas cuando se está instalando un desarrollo a medida, ya que lo habitual es que la propia instalación de un producto cerrado se encargue de esta tarea. No obstante puede darse el caso en el que sea necesario mover una cuenta de máquina a una nueva instancia o crear una nueva cuenta en la misma, como por ejemplo migraciones o actualizaciones a versiones más recientes de la base de datos. Sea cual sea el motivo, si para el proceso se intenta utilizar la interfaz gráfica de SQL Server Management Studio, se puede comprobar que del todo imposible crear un inicio de sesión para una cuenta de máquina, ya que la propia ventana de selección de cuentas no permite incluirlas o enumerarlas.



    Imagen 2: La interfaz gráfica de SSMS no permite elegir el tipo de objeto (object type) máquina ya que no aparece tan siquiera listado.


    En cambio, en otros servicios, como la administración de cuentas de usuario del sistema operativo, es posible ver e incluir cuentas de máquina.


    Imagen 3: La consola de administración de usuarios sí permite elegir el tipo de objeto (object type) máquina.


    Si de todas formas se conoce y se intenta escribir el nombre completo de la cuenta de máquina, al chequearla o se intenta directamente aceptar en el cuadro de diálogo, el sistema mostrará un error indicando que no ha podido localizar el nombre especificado dentro de los objetos de tipo usuario, grupo o cuentas predefinidas.


    Imagen 4: Error al intentar introducir manualmente la cuenta de máquina.


    Resolución

    SQL Server Management Studio no permite la selección de cuentas de máquina desde la interfaz gráfica por características de diseño. La ventana de selección de cuentas del Directorio Activo pertenece a la librería común del sistema operativo, al igual que el cuadro de diálogo para abrir o guardar un fichero o el de seleccionar un directorio de destino. Cuando una aplicación desea utilizar esta ventana de selección de cuentas debe indicarle de antemano el tipo de objetos del Directorio Activo que desea que aparezcan listados y en este caso SSMS le solicita que muestre cuentas de usuario, grupos y cuentas predeterminadas. Esto no significa que en futuras revisiones no se cambie este comportamiento.

    En este caso la única forma posible de dar de alta una cuenta de máquina es a través de un comando Transact-SQL. Como recordatorio, la cuenta de máquina corresponde al nombre de la máquina (que puede obtenerse desde la línea de comandos con el comando HOSTNAME) precedido por el nombre del dominio donde se encuentra y seguido del símbolo de dólar ($). Es prácticamente seguro que esta opción no funcione para equipos fuera de dominio:

    De todas formas, la solución recomendada es, siempre que lo permita el producto o el desarrollo que utilice la cuenta, crear un grupo de usuarios local o local de dominio en la consola de administración de seguridad del sistema operativo y añadir la cuenta de máquina para luego crear una cuenta de inicio de sesión en SQL Server vinculada al grupo. También se recomienda como norma general evitar el uso de las cuentas predefinidas “NT AUTHORITY\System” o “NT AUTHORITY\NETWORK SERVICE” en los desarrollos que accedan a recursos tales como ficheros o bases de datos y que de forma alternativa se utilicen cuentas de usuario local o de dominio específicas para cada propósito. De esta manera se logra identificar qué servicio o aplicación en concreto está accediendo a cada recurso y se protege al sistema operativo de posibles fallos de seguridad.

    Referencias

    Cómo crear un inicio de sesión de SQL Server

    http://msdn.microsoft.com/es-es/library/aa337562.aspx

    CREATE LOGIN (Transact-SQL)

    http://msdn.microsoft.com/es-es/library/ms189751.aspx

    SQL Server 2005 Security Best Practices - Operational and Administrative Tasks

    http://sqlcat.com/whitepapers/archive/2007/12/16/sql-server-2005-security-best-practices-operational-and-administrative-tasks.aspx

    Directory Object Picker

    http://msdn.microsoft.com/en-us/library/ms675899(v=vs.85).aspx

     

    - Jesús Nacimiento Casanova, Microsoft Premier Field Engineer

  • Esecuele Sin Fronteras

    Cómo Abrir Fácilmente los Puertos del Firewall de Windows para SQL Server

    • 0 Comments

    El pasado día, tras realizar una instalación de SQL Server 2008 en mi portátil con Windows 7, me encontré sin poder conectar a la instancia utilizando SQL Server Management Studio (SSMS). Recordaba que debido a los cambios introducidos en el Firewall de Windows Server 2008 y Windows Vista esto se debía con seguridad a puertos requeridos por SQL Server que no estaban abiertos en el Firewall.

    La sección Configurar Firewall de Windows para permitir el acceso a SQL Server de la documentación en línea de SQL Server incluye información sobre cómo abrir en el Firewall de Windows los puertos requeridos por los diferentes servicios de SQL Server. Sin embargo, buscando esta información descubrí una manera mucho más sencilla de abrir estos puertos en el artículo de la Knowlege Base KB968872:

    25082009B

    El artículo incluye la opción de resolución automática Microsoft "Fix it" que permite solucionar de manera sencilla el problema en cuestión a través de un sencillo programa de setup. El setup de "Fix it" en este artículo está diseñado para Windows Server 2008 pero el script que es finalmente ejecutado por este setup está incluido en el mismo artículo y puede ser ejecutado tanto en Windows Vista como en Windows 7:

    @echo =========  SQL Server Ports  ===================
    @echo Enabling SQLServer default instance port 1433
    netsh firewall set portopening TCP 1433 "SQLServer"
    @echo Enabling Dedicated Admin Connection port 1434
    netsh firewall set portopening TCP 1434 "SQL Admin Connection"
    @echo Enabling conventional SQL Server Service Broker port 4022 
    netsh firewall set portopening TCP 4022 "SQL Service Broker"
    @echo Enabling Transact-SQL Debugger/RPC port 135
    netsh firewall set portopening TCP 135 "SQL Debugger/RPC"
    @echo =========  Analysis Services Ports  ==============
    @echo Enabling SSAS Default Instance port 2383
    netsh firewall set portopening TCP 2383 "Analysis Services"
    @echo Enabling SQL Server Browser Service port 2382
    netsh firewall set portopening TCP 2382 "SQL Browser"
    @echo =========  Misc Applications  ==============
    @echo Enabling HTTP port 80
    netsh firewall set portopening TCP 80 "HTTP"
    @echo Enabling SSL port 443
    netsh firewall set portopening TCP 443 "SSL"
    @echo Enabling port for SQL Server Browser Service's 'Browse' Button
    netsh firewall set portopening UDP 1434 "SQL Browser"
    @echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)
    netsh firewall set multicastbroadcastresponse ENABLE

    Al ejecutar este script en Windows 7 se mostrarán varios mensajes de "warning" ya que el comando netsh firewall se encuentra depreciado en Windows 7 (netsh advfirewall firewall es el comando recomenado) aunque el script funcionará en cualquier caso.

    ¡Gracias por este script al equipo de Microsoft "Fix it"!

    -- Jorge Pérez Campo, Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    Cómo sincronizar dos tablas usando SQL Server Integration Services (SSIS)-Parte I de II

    • 1 Comments

    Hay diferentes situaciones en las que un administrador de base de datos necesita mantener dos tablas sincronizadas. Una de estas situaciones se da cuando es preciso mantener una copia de una talba en un repositorio de Datawarehouse que es usado como solución de archivo o generación de informes.

    SQL Server proporciona un método robusto para mantener datos sincronizados en diferentes bases de datos usando Replicación, pero hay situacones en las que nuestra necesidad es sólo la de mantener sincronizadas un par de tablas y no deseamos tener que configurar una topología de replicación en la instancia.

    El siguiente artículo está divido en dos partes: la Parte I explica cómo actualizar una tabla destino con la información que es añadida en una tabla origen, mientaras que la Parte II explica cómo replicar o propagar cualquier cambio que suecede en la información ya existente de la tabla origen en la tabla destino.

    Este procedimiento se basa en el siguiente escenario: Una "tabla A" en la "base de datos A" replica periódicamente la nueva información añadida en una "tabla B" en la "base de datos B". La "tabla A" es actualizada periódicamente con nuevos registros y necesitamos copiar esa informaicón en la "tabla B". La implementación final tendrá el siguiente aspecto en SQL Server Business Intelligence Development Studio (BIDS):

     

    Veamos cómo funciona esto:

    1. "Source Table" es la "tabla A" en la "base de datos A" mientras que "Dest Table" es la tabla destino "B" en la "base de datos B". Empezamos creando dos conectores OLEDB diferentes en el componente de Data Flow en SSIS utilizando tanto la tabla origen como la tabla destino como orígenes de datos.

    2. Necesitamos realizar una operación de JOIN en los dos orígenes de datos anteriores para copiar la información que queremos copiar de una tabla en la otra. Para que este JOIN funcione correctamente los datos deben de estar ordenados; esto se encuentra descrito en el siguiente enlace de MSDN:

    En Integration Services, las transformaciones Mezclar y Combinación de mezcla requieren datos ordenados en sus entradas. Los datos de entrada deben estar ordenados físicamente, y se deben establecer opciones de ordenación en las salidas y en las columnas de salida del origen o en la transformación de nivel superior. Si las opciones de ordenación indican que los datos están ordenados, pero en realidad no lo están, los resultados de la operación de mezcla o combinación de mezcla son impredecibles.

    En el operador de "Merge Join" es donde separamos los datos que han sido añadidos en la tabla origen (los datos que necesitamos) de los que no han sido añadidos (los que no necesitamos) desde la última ejecución del paquete de SSIS. En nuestro caso en la talba origen (a la izquierda) se han includio todas las columnas que queremos mantener sincronizadas mientras que la tabla destino (a la derecha) contiene solo el registro que correponde a la Clave Primaria, la columna "No_" en este caso. Este sería la descripción de la tarea:

     

    Esta es la parte importante del proceso: el operador Left Outer Join recupera todos los registros en la tabla origen pero aquellos que no exiten en la tabla destino son recuperados como NULL en la columna "No_" usada en el Join (columna Join Key). Esto se encuentra también descrito en la documentación del producto:

    Para incluir todos los productos, independientemente de si se ha escrito una revisión para alguno de ellos, utilice una combinación externa izquierda ISO. Ésta es la consulta:

    LEFT OUTER JOIN incluye en el resultado todas las filas de la tabla Product, tanto si hay una coincidencia en la columna ProductID de la tabla ProductReview como si no la hay. Observe que en los resultados donde no hay un Id. de revisión de producto coincidente para un producto, la fila contiene un valor nulo en la columna ProductReviewID.

    3. A continuación necesitamos separar los datos que necesitamos de los que no han cambiado. Para ello usamos una tarea de "Conditional Split" que se encarga de salvar la información para aquellos registros donde el campo clave "No_" devuelve NULL; dicho de otra forma, se encarga de salvar la información sólo de los registros nuevos. Aquí se muestra una descripción de esta tarea en BIDS:

     

    4. Finalmente realizamos un INSERT en los datos resultantes del operador "Conditional Split" en la tabla destino, que es la misma que usamos también como origen al principio del todo.

    En este ejemplo la tarea de JOIN está configurada de tal modo que puede ser reutilizada tantas veces como sea necesario, los registros en la tabla destino no se duplicarán con la información de la tabla origen, sólo los nuevos registros serán incorporados en el destino.

    Jorge Pérez Campo - Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    Upgrade a SQL Server 2008 R2 en español en un Windows inglés.

    • 0 Comments

    Antes de empezar tenemos que aclarar que esta situación no está soportada. Las combinaciones soportadas para los distintos idiomas de Windows/SQL son las siguientes:

    - SQL Server Ingles puede instalarse sobre cualquier versión de Windows, sea cual sea su idioma.

    - SQL Server localizado para un idioma solo puede instalarse en un Windows del mismo idioma. También es posible instalarlo en un Windows ingles con el paquete “MUI” español instalado y activo para la cuenta que instala SQL.

    Para más información: http://technet.microsoft.com/en-us/library/ee210665.aspx

    Hace unos días me encontré con un caso en el que se pretendía actualizar una instancia de SQL Server 2008 a SQL Server 2008 R2 la cual finalizaba inesperadamente mientras se instalaban las “Support Files”

    image

    Error durante el upgrade de SQL Server 2008 a 2008 R2.

    Como podemos ver el “Locale ID” del paquete que queremos instalar es el 3082 (Español – Alfabetización Internacional) y la máquina local tiene el “locale” (LCID) en 1033 (Inglés – Estados Unidos)

    Como hemos comentado esta situación no está soportada pero nuestro objetivo es actualizar la instancia por tanto nos pusimos a analizar los logs de instalación de SQL Server. (Normalmente están localizados en “C:\Program Files\Microsoft SQL Server\{Version}\Setup Bootstrap\LOG” donde {version} es: 80 para SQL 2000, 90 para SQL 2005, 100 para SQL 2008 y 2008 R2

    En el archivo Summary del log nos encontramos:

    Exit code (Decimal):           -2068054013 (0x84BC0003)

    Exit facility code:            1212 (0x4BC)

    Exit error code:               3 (0x0003)

    Como podemos ver en: http://msdn.microsoft.com/en-us/library/ms681382(v=vs.85).aspx el error código 3 corresponde con: ERROR_FILE_NOT_FOUND

    Si vamos al final del log “Detailed_ComponentUpdate.txt” nos encontramos lo siguiente:

    2010-11-16 13:21:56 Slp: Target package: "D:\SQL Server 2008 EE\SQL_Svr_2008_R2\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi"

    2010-11-16 13:21:56 Slp: InstallPackage: MsiInstallProduct returned the result code 3.

    2010-11-16 13:21:56 Slp: Watson Bucket 1

    Como podemos ver el error nos da porque no puede encontrar D:\SQL Server 2008 EE\SQL_Svr_2008_R2\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi. El instalador prueba varias rutas antes de fallar así que ponemos una traza de procmon para ver que rutas intenta. El resultado de procmon es el siguiente.

    "12:03:43,4193775","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\x64\SqlSupport.msi","PATH NOT FOUND",""

    "12:03:43,4194404","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND",""

    "12:03:43,7781168","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sql2008support\x64\SqlSupport.msi","PATH NOT FOUND",""

    "12:03:43,7781803","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sql2008support\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:09,4823169","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\x64\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:09,4824232","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:11,0054432","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sql2008support\x64\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:11,0055509","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sql2008support\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:18,7159743","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\x64\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:22,8443950","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\x64\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:22,8445045","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:22,9637093","setup100.exe","2680","CreateFile","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a"

    "12:04:22,9919463","setup100.exe","2680","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:23,4191552","msiexec.exe","5508","QueryOpen","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND",""

    "12:04:23,4192983","msiexec.exe","5508","CreateFile","D:\SW_SQLSrv2008R2Ent\1033_ENU_LP\x64\setup\sqlsupport_msi\SqlSupport.msi","PATH NOT FOUND","Desired Access:

    El instalador busca en varias rutas, pero siempre dentro de la rama 1033_ENU_LP que corresponde al idioma inglés.

    La primera impresión es que estábamos actualizando con el paquete equivocado y que la instalación original estaba en inglés. Cuando instalamos con el paquete ingles la instalación de las support files se hace correctamente pero al llegar a la comprobación de requisitos nos encontramos con el siguiente fallo que nos evita seguir la instalación.

    BlockCrossLanguageUpgrade – Failed

    ¡La instalación detecta que el idioma de SQL instalado y el del upgrade que queremos hacer son distintos!

    A continuación sacamos un listado de las instancias detectadas por el instalador:

      Sql Server 2008 X Database Engine Services 1033 Enterprise Edition 10.1.2531.0

      Sql Server 2008 X Database Engine Services 3082 Enterprise Edition 10.1.2531.0 

      Sql Server 2008 Full-Text Search 1033 Enterprise Edition 10.0.1600.22      

      Sql Server 2008 X Analysis Services 1033 Enterprise Edition 10.1.2531.0       

      Sql Server 2008 X Analysis Services 3082 Enterprise Edition 10.1.2531.0 

      Sql Server 2008 X Reporting Services 1033 Enterprise Edition 10.1.2531.0  

      Sql Server 2008 X Reporting Services 3082 Enterprise Edition 10.1.2531.0    

      Sql Server 2008 Management Tools - Basic 3082 Enterprise Edition 10.1.2531.0       

      Sql Server 2008 Management Tools – Complete 3082 Enterprise Edition 10.1.2531.0   

      Sql Server 2008 Client Tools Connectivity 3082 Enterprise Edition 10.1.2531.0    

      Sql Server 2008 Integration Services 3082 Enterprise Edition 10.1.2531.0 

    El instalador detecta que el motor de la base de datos, Analysis Services y Reporting Services de la instancia X están instalados en Español(3082) e Ingles(1033), algo que resulta bastante extraño.

    Cuando instalas SQL Server en un idioma que no coincide con el del sistema operativo es normal encontrar estas entradas en el log de SQL Server. Esto indica que la instalación es española y el sistema operativo es inglés.

    Para estar dentro de soporte sin reinstalar todo de nuevo la única solución es instalar los MUI(Multilingual User Interface) para el idioma en el que tenemos instalando SQL Server, podemos descargarlos desde aquí http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e9f6f200-cfaf-4516-8e96-e4d4750397ff&displaylang=en. Una vez que se instaló el MUI y se cambió la cuenta con la que se hace la instalación a español SQL se instaló sin ningún problema.

    Pablo Gavela López - Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    Uso de campos XML en SQL SERVER

    • 0 Comments

    INTRODUCCION.-

    Hemos observado en algunos casos en determinados proyectos que usan SQL SERVER se implementan campos de tipo TEXT para almacenar datos de XML.

    Desde la versión de SQL SERVER 2005 existe la posibilidad o bien de leer archivos de XML y poder manipularlos o almacenarlos como un campo de XML dentro de una tabla de SQL SERVER.

    Nuestro pequeño post girará en entorno al nuevo tipo de dato XML que nos permite realizar operaciones desde la lectura, indexación por path, valores y tags así como poder actualizar sólo la parte del XML sin tener que sustituir todo el contenido del campo, ahorrando muchas de las operativas de manipulación por parte de desarrollador.

    Con el fin de crear una pequeña guía de trabajo del uso de este nuevo tipo de datos, os mostraremos varios detalles del mismo.

    TABLA DE EJEMPLO.-

    Lo primero que vamos a realizar será crear una tabla que llamaremos EjemploXML que contendrá dos campos:

    • XML_ID de tipo integer y autoincremental que nos permitirá crear una clave única para el ejemplo.
    •  
    • XML_Data de tipo XML que nos permitirá almacenar los datos en XML.

    clip_image001[22]

     

    OPERACIONES.-

    Una vez ya tenemos la tabla vamos a realizar operaciones básicas como:

    Insertar varios registros pudiendo utilizar dos formas:

    • SQL Directa: Insert Into EjemploXML(XML_Data) Values('<cliente>Juan Perez</cliente>')

     

    • O más avanzada usando una variable de tipo XML:

    DECLARE @xml AS XML

    SET @xml = '<Clientes> <Cliente> <ClienteID>2005</ClienteID> <Nombre>25</Nombre> </Cliente> </Clientes>’

    INSERT INTO EjemploXML(XML_Data) Values (@xml)

    Una vez hemos insertado estos datos, podemos ya realizar nuestras propias sentencias de SQL. Por un lado:

     

    • SELECT * FROM EjemploXML , que nos mostraría línea a línea los registros y su contenido XML.

     

     

    • Si queremos filtrar por algún contenido del XML, basta con añadir una serie de operadores que nos permitirán filtrar cualquier de los datos disponibles:

    SELECT * FROM EjemplosXML where xml_data.exist('/Clientes/Cliente/ClienteID[text()=10]')=1

     

    Comentar dos casos en relación a las búsquedas:

     

    • Cuando existen muchos XML por procesar, podemos como cualquier base de datos crear índices, pero estos índices al ser campos del tipo XML, son “algo especiales en su construcción”, por ejemplo:

     

    • Lo primero crearemos un índice primario como cualquier otro que podamos crear: CREATE Primary XML INDEX xml_idx_1 ON EjemploXML(XML_Data) Con este índice indicaremos a SQL SERVER que este campo XML tiene un índice.

     

     

    CREATE XML INDEX xml_idx_1_a ON EjemploXML(XML_Data) USING XML INDEX xml_idx_1 FOR PATH

    CREATE XML INDEX xml_idx_1_v ON EjemploXML(XML_Data) USING XML INDEX xml_idx_1 FOR value

    CREATE XML INDEX xml_idx_1_p ON EjemploXML(XML_Data) USING XML INDEX xml_idx_1 FOR property

     

    Finalmente, nos queda la posibilidad de bien, borrar o actualizar los datos de un XML. Para ello tenemos los siguientes métodos explicados en la siguiente URL: http://msdn.microsoft.com/es-es/library/ms177454.aspx

    NOTAS GENERALES.-

     

    Comentar por último que los nuevos tipos de datos de XML no sólo pueden usarse como campos de tablas, sino, que tienen otras funcionalidades como:

     

    • Devoluciones de valores de funciones UDF
    • Parámetros de procedimientos almacenados y funciones
    • Tipos de variables
    •  

    A parte, otras de las ventajas de que disponemos, es que podemos aplicar un constraint para evitar que un XML no esté bien formado, es decir, validar esquemas de XML o bien podemos añadir el contenido directamente del XML a través del comando BULK INSERT

  • Esecuele Sin Fronteras

    Error en la solicitud de inicio del servicio 'SQLBrowser' Durante la Instalación de SQL Server 2008

    • 11 Comments

    El pasado día me encontré con un problema bastante curioso durante la instalación de SQL Server 2008 y creo que merece la pena compartir aquí lo que descubrí. En este caso mi cliente estaba llevando a cabo una instalación de SQL Server 2008 en un ordendador con Windows XP SP3 para dar soporte a un paquete de ERP instalado localmente.

    El proceso de instalación de SQL Server 2008 parecía funcionar bien inicialmente pero fallaba en un determinado punto con el siguiente mensaje de error:

    Error en la solicitud de inicio del servicio ‘SQLBrowser’. Haga clic en Reintentar para reintentar la accion o haga clic en Cancelar para cancelar el proceso de instalación.

    Pulsando en el botón Reintentar llevaba a cabo un nuevo intento de arrancar el servicio, pero fallaba de nuevo con el mismo error de modo que no había otra opción que no fuese cancelar el proceso de instalación.

    El Visor de Eventos de Windows no mostraba ninguna pista acerca del origen del error de manera que decidí comprobar el fichero de registro de instalación de SQL Server 2008 que se encuentra en la carpeta C:\Archivos de Programa\Microsoft SQL Server\100\Setup Bootstrap\Log. Existen diferentes archivos de registro en esta carpeta y cada uno de ellos proporciona información específica para un componente de SQL Server (SSIS, AS, Motor de Base de Datos, Herramientas Cliente, etc.). El fichero Detail.txt incluye información detallada de proceso global de instalación y es normalmente el primer fichero que abro a la hora de investigar un problema de instalación; esto fue lo que encontramos en nuestro caso:

    2009-05-14 17:25:13 SQLBrowser: The last attempted operation: Iniciando el servicio SQL Server Browser 'SQLBrowser' y esperando hasta '900' segundos para que se complete el proceso. .
    2009-05-14 17:25:13 Slp: Prompting user if they want to retry this action due to the following failure:
    2009-05-14 10:25:13 Slp: ----------------------------------------
    2009-05-14 17:25:13 Slp: The following is an exception stack listing the exceptions in outermost to innermost order
    2009-05-14 17:25:13 Slp: Inner exceptions are being indented
    2009-05-14 17:25:13 Slp:
    2009-05-14 17:25:13 Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException
    2009-05-14 17:25:13 Slp: Message:
    2009-05-14 17:25:13 Slp: Error en la solicitud de inicio del servicio 'SQLBrowser'.
    2009-05-14 17
    :25:13 Slp: Data:
    2009-05-14 17:25:13 Slp: Feature = SQL_Browser_Redist_SqlBrowser_Cpu32

    Aquí podíamos ver que efectivamente el servidio SQLBrowser había sido creado pero no podía ser arrancado por alguna razón. A continuación pasé al archivo de registro de instalación Summary.txt que proporciona un resumen de los eventos llevados a cabo durante el proceso; este fichero puede encontrarse también bajo la carpeta \LOG e incluye un lista de qué componentes han sido instalados con éxito y cuáles no. Lo interesante en este caso es que el error en este fichero no apuntaba al servicio de SQL Browser sino al componente MSXML 6.0 (el motor XML de Microsoft):

    Detailed results:
      Feature:                       Servicios de Motor de base de datos
      Status:                        Error: consulte los registros para obtener detalles
      MSI status:                    Error: vea los detalles a continuación
      MSI error code:                0x5EBE5729
      MSI log file location:         C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Msxml6_Cpu32_1.log

    Buscando dentro del fichero indicado se podía ver los siguiente (Msxml6_Cpu32_1.log):

    MSI (s) (30:58) [17:22:37:661]: Note: 1: 1708
    MSI (s) (30:58) [17:22:37:661]: Producto: MSXML 6.0 Parser (KB933579) -- Error en la instalación.

    MSI (s) (30:58) [17:22:37:661]: Windows Installer instaló el producto. Nombre del producto: MSXML 6.0 Parser (KB933579). Versión del producto: 6.10.1200.0. Idioma del producto: 3082. Resultado de la instalación: 1603.

    MSI (s) (30:58) [17:22:37:661]: Cleaning up uninstalled install packages, if any exist
    MSI (s) (30:58) [17:22:37:661]: MainEngineThread is returning 1603

    Estaba claro por tanto que el servicio SQL Browser no era el único componente que fallaba durante el proceso de instalación, el motor de Microsoft para XML 6.0 estaba también fallando. Observando los tiempos de los ficheros Detail.txt y Msxml6_Cpu32_1.log se podía comprobar además que este último mostraba el error antes; en otras palabras, el error de instalación de MSXML estaba teniendo lugar antes del error de instalación de SQL Browser. Volví de nuevo al fichero Detail.txt para confirmar este punto:

    2009-05-14 17:22:36 Slp: ----------------------------------------------------------------------
    2009-05-14 17:22:36 Slp: Running Action: Install_Msxml6_Cpu32_Action
    2009-05-14 17:22:36 Slp: Target package: "D:\x86\setup\x86\msxml6.msi"
    2009-05-14 17:22:37 Slp: InstallPackage: MsiInstallProduct returned the result code 1603.
    2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\Microsoft SQL Server to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_Microsoft SQL Server.reg_
    2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_Windows_CurrentVersion_Uninstall.reg_
    2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\MSSQLServer to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_MSSQLServer.reg_
    2009-05-14 17:22:43 Slp:
    2009-05-14 17:22:43 Slp: Watson bucket for Msi based failure has been created
    2009-05-14 17:22:43 Slp: No retry-able MSI return code detected.
    2009-05-14 17:22:43 Slp: Checkpoint: INSTALL_MSXML6_CPU32_ACTION
    2009-05-14 17:22:43 Slp: Completed Action: Install_Msxml6_Cpu32_Action, returned False
    2009-05-14 17:22:43 Slp: Error: Action "Install_Msxml6_Cpu32_Action" failed during execution.

    Al revisar la información de "Agregar o Quitar Programas" en el Panel de Control de Widnows podía ver que el componente MSXML 6.0 se encontraba de hecho instalado. Este es un componente compartido instalado por SQL Server 2008 pero en mi caso el cliente no estaba seguro de si este estaba ya allí antes de la instalación de SQL Server. Decidí desinstalar este componente usando el propio "Agreagar o Quitar Progamas" y lanzar la instalación de SQL Server 2008 de nuevo. Esta vez la instalación se completó sin errores.

    En este caso el error inicial de SQL Server Browser era confuso al ser el primer error que se mostraba en la interfaz gráfica. Solo mirando en los ficheros de registro de instalación de SQL Server pudimos comprobar que existía un problema anterior en la instalación de los componentes MSXML 6.0.

    Otra posible forma de descubrir este error es mediante el fichero de registro del Bucket de Watson que se genera al producirse un error durante el proceso de instalación y que se encuentra en el mismo directorio de Log:

    28052008

    En nuestro caso el contenido de este fichero era:

    Watson bucket data:
      Bucket param 1: 10.0.1600.22
      Bucket param 2: 6.10.1200.0
      Bucket param 3: msxml6.msi
      Bucket param 4: 0x2D2816FE
      Bucket param 5: 0x5EBE5729
      Bucket param 6: Install_Msxml6_Cpu32_Action
      Bucket param 7:
      Bucket param 8:
      Bucket param 9:
      Bucket param 10:

    He revisado las notas referentes al SP1 para SQL Server 2008 y este problema parece estar resuelto en este Paquete de Servicio de forma que otra opción para evitar este problema sería la de instalar una versión de SQL Server 2008 con el Service Pack ya integrado (esto es lo que se conoce en Inglés como Slipstreaming). Esta funcionalidad es nueva en SQL Server 2008 y permite a los administradores de bases de datos integrar Paquetes de Servicio en los medios de intalación reduciendo los tiempos de despliegue y evitando problemas conocidos.

    - Jorge Pérez, Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    Mitos y verdades de la reducción de archivos en SQL (“shrink files/database”)

    • 8 Comments

    Últimamente he tenido varias cuestiones relacionas con la reducción de archivos, por lo que escribo este post para arrojar algo de luz en este aspecto.

    Los archivos de SQL (tanto el de datos como el log de transacciones) tienen espacio marcado como “libre”, es decir, espacio asignado al archivo, pero que en este momento no contiene información, bien porque aún no se ha escrito, bien porque los datos que contenía se han borrado. SQL, por sí mismo, no libera este espacio, sino que lo mantiene en el archivo, marcándolo como libre, para ser utilizado cuando se necesite.

    La primera pregunta que debemos hacernos antes de realizar una reducción (shrink) es: ¿realmente quiero hacerlo? Hay una razón por la que SQL no libera ese espacio: normalmente es espacio que se va a necesitar durante las operaciones diarias. Tener espacio libre en los archivos es una buena práctica, porque así evitamos operaciones de crecimiento (muy pesadas).

    Mi recomendación personal es que nunca se hagan “shrinks” como parte de la tarea de mantenimiento, y que tampoco se configure de forma automática (autoshrink). Cualquiera de estas opciones probablemente desemboque en el siguiente escenario: Durante la tarea de mantenimiento, se libera espacio. Al empezar las operaciones diarias, se necesita espacio, por lo que hay una acción de autocrecimiento. Las consecuencias: Operaciones pesadas y fragmentación de los datos, ambas penalizan gravemente el rendimiento.

    Mi recomendación, por lo tanto, es realizar shrinks sólo cuando haya habido un borrado masivo de datos o cuando haya graves problemas de espacio en disco.

    Una vez que hemos decidido que queremos reducir el espacio, una situación muy frecuente es, utilizando la consola gráfica, elegir tareas en la base de datos, elegir reducir archivos, y utilizar la opción “Liberar espacio no utilizado” (release unused space). La tarea termina muy rápidamente, y en contra de lo esperado, no se libera espacio, o mucho menos del esperado.

    Cuando se especifica esta opción, se libera el espacio no utilizado que se encuentra “al final” del archivo: sólo se libera espacio si el último “extent” (conjunto de 8 páginas) se encuentra completamente libre, en cuyo caso se libera, y se comprueba el anterior, deteniéndose cuando uno de los extents no está completamente libre. Por eso, si el espacio marcado como libre se encuentra repartido entre diferentes extents que no son el último asignado a la base de datos, no se liberará el espacio que se había estimado.

    Si este es el caso, podemos liberar espacio eligiendo la opción: Reorganizar archivos antes de liberar espacio no utilizado (Reorganize files before releasing unused space). De esta manera, se “mueve” el espacio marcado como libre al final del archivo, y por lo tanto se puede liberar, reduciéndose el espacio ocupado en disco.

    Espero que sea de utilidad.

    Un saludo.  

     

    Raquel Vicente

    Ingeniero de Soporte de SQL Server

  • Esecuele Sin Fronteras

    Cómo sincronizar dos tablas usando SQL Server Integration Services (SSIS)-Parte II de II

    • 1 Comments

    Por favor, utiliza este link para acceder a la primera parte de este artículo.

    En esta segunda parte empezaremos con el mismo escenario donde una “tabla A” en una “base de datos A” tiene que ser sincronizada con una “tabla B” en una “base de datos B”. Durante la primera parte de este artículo discutimos cómo trabajar con los nuevos registros añadidos a la “tabla A” pero no explicamos cómo sincronizar los registros ya existentes que también eran actualizados en la “tabla A”.

    Dentro de SSIS podemos emplear diferentes métodos para recononcer aquellos registros que difieren entre la tabla origen y la tabla destino. Por ejemplo, podemos usar el operador EXCEPT para extraer esas diferencias y actualizar la tabla destino a continuación. En este caso vamos a usar la utilidad tablediff, que permite sincronizar ambas tablas rápidamente. Esta utilidad se emplea en la Replicación de SQL Server para recopilar información detallada acerca de las diferencias entre dos tablas.

    Lo mejor de tablediff es que no sólo permite comparar tablas sino que además permite generar un script que incorpora las diferencias de manera que las tablas pueden ser sincronizadas simplemente ejecutando el script. La limitacion de tablediff es que sólo funciona con servidores SQL Server así que si el objetivo es sincronizar dos tablas con algún otro motor de base de datos no se podrá emplear este método.

    En mi caso esto es lo que hice para sincronizar las dos tablas:

    1. Nos aseguramos de que la utilidad tablediff está intalada en el servidor de SQL Server. El ejecutable tablediff.exe se puede encontrar bajo el directorio C:\Program Files\Microsoft SQL Server\<version>\COM

    2. Añadimos tablediff.exe a la variable Path de Windows desde Computer Properties > Advanced System Settings > Advanced > Environment Variables > System Variables > PATH

    3. Nos aseguramos de que xp_cmdshell está habilitada ejecutando sp_configure desde SQL Server Management Studio (SSMS):

    Imagen1

    Por favor, lee detenidamente la documentación de xp_cmdshell y entiende las implicaciones de usar esta opción en el entorno. xp_cmdshell crea un proceso Windows con los mismos privilegios que los de la cuenta de servicio de SQL Server, lo que significa que los miembros del grupo sysadmins pueden acceder a funciones a las que no tendrían acceso sólo con su cuenta de Windows. Por defecto sólo los miembros del rol de servidor sysadmin en SQL Server están autorizados a ejecutar este procedimiento almacenado extendido. Si tu compañía no dispone de una política para asignar permisos a las cuentas de servicio de SQL Server donde se especifique claramente quién pertenece al este rol, evalua detenidamente la conveniencia de habilitar xp_cmdshell.

    4. Utilizando elmismo proyecto de SSIS que creamos durante la primera parte de este artículo, creamos dos tareas del tipo “Execute SQL Task”, bajo la sección de Control Flow en BIDS. La primera tarea, llamada “Execute tablediff” en el ejemplo, se encargará de ejecutar el comando tablediff.exe. Este es un ejemplo del código en mi caso:

    exec master..xp_cmdshell 'tablediff.exe -sourceserver SQL2008R2\KILIMANJARO64 -sourcedatabase SSISDBSource -sourcetable Customer -destinationserver SQL2008R2\KILIMANJARO64 -destinationdatabase SSISDBDest -destinationtable Customer -f C:\Temp\Diff'

    imagen2

    La parte importante en este paso es el modificador –f, que es quien se encarga de crear el script de T-SQL con los cambios que tienen que ser implmentados en la tabla de destino. Este es un ejemplo de este script generado automaticamente:

    imagen3

    La segunda tarea, llamada “Execute SQL Script” en el ejemplo, se encargará de ejecutar contra la base de datos el script generado en C:\Temp\Diff.sql, llevando a cabo las modificaciones requeridas desde la tabla origen en la tabla destino:

    imagen4

    5. Opcionalmente podemos combinar la tarea de “Data Flow” que creamos durante la primera parte de este artículo con estas dos tareas y disponer de un paquete de sincronización completo:

    imagen5

    Jorge Pérez Campo - Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    Migración de Reporting Services 2005 a Reporting Services 2008

    • 0 Comments

    ¿Alguna vez has pensado en migrar a Reporting Services 2008….

    ….  pero no sabías con que te ibas a encontrar?

     

    Antes de tomar la decisión sobre la migración de nuestro Reporting Services a 2008, junto con sus informes, modelos, orígenes de datos... es útil considerar los diferentes escenarios que nos podemos encontrar, y echarle un vistazo a la manera en la que Reporting Services realiza la actualización de los informes.

     

    En este artículo hemos recopilado información útil que le puede ayudar a planificar mejor el proceso de migración a Reporting Services 2008:

     

    1.       Escenarios y su resultado al efectuar la migración

    2.       Proceso de actualización automática de un informe de 2005 a 2008 desde el Administrador de Informes

    3.       Actualización de informes desde el diseñador de informes.

    4.       El asesor de actualizaciones (Upgrade Advisor)

    5.       Enlaces con pasos a seguir para hacer la migración o la actualización a Reporting Services 2008

     

     

    1.       Escenarios y su resultado al efectuar la migración

     

    Escenario

                 Estado

    Aplicaciones hechas para RS 2005

            Funcionarán

    Aplicaciones hechas para RS 2000

            APIs SOAP de RS 2000 no están soportados

            Acceso a URL funcionará

    Base de datos de RS en de SQL 2005

            Funcionará

    Base de datos de RS en SQL 2000

            No está soportado

    Integración con Sharepoint

            Existe un nuevo Add-in para 2008

    WebParts v2 SharePoint

            Soportado

    Implementación en uno o varios servidores

            Sigue soportado

    Implementación en Scale-out

            Sigue soportado

    RDL, RDLC

                  Estado

    RS 2005 RDL, RS 2000 RDL

            Puede publicar directamente a 2008

            Formato RDL 2005 se preserva

    Report Designer 2000

            No se pueden publicar a 2008

    Report Designer 2005

            Se pueden publicar a 2008

    Report Designer 2008

            Se actualizan de 2000 y 2005

            Se pueden crear en 2008 solo

            Se pueden publicar en 2008 solo

    ReportViewer de VS 2005

    ReportViewer de VS 2008

            Soportado  (puede mostrar 2008)

            2008 RDLC no soportado en modo local ¨todavía¨

     

     

    2.       Proceso de actualización automática de un informe de 2005 a 2008 desde el Administrador de Informes

     

    El siguiente diagrama explica el proceso que sigue Reporting Services al intentar abrir un informe de una versión de 2005 con el Administrador de Informes de 2008:

    1.       Cuando se ejecuta el informe desde el Administrador de Informes, Reporting Services comprueba si el informe ha sido creado con una versión anterior.

    2.       Si el informe ha sido creado con la versión de 2005, Reporting Services lo intentará convertir a formato 2008, creando un formato intermedio. Si surgen errores durante la actualización, el informe se marcará internamente para ser ejecutado siempre con el motor de Reporting Services 2005, y se reiniciará la ejecución de nuevo

    3.       Si el informe está marcado para ejecución con 2005, ya no intentará actualizarlo nunca más y se ejecutará siempre con el motor de RS 2005 pero no podrá beneficiarse de la mejora en el sistema de memoria ni en el motor de informes de la versión de 2008.

     

     

    3.       Actualización de informes desde el diseñador de informes.

    Si intentamos abrir un informe creado con RS 2005 desde el diseñador de informes de 2008, Reporting Services intentará actualizar el informe a 2008. Si encontrase algún error, mostraría un mensaje al usuario explicado que se han encontrado errores y daría la posibilidad de convertir el informe (perdiendo la funcionalidad no admitida) o no. Aunque se elija la opción de actualizar el informe a 2008, se creará una copia automáticamente del informe de la versión 2005 en el mismo directorio que el informe original y se le dará el mismo nombre seguido de ¨_ Backup¨

    Si los informes hubiesen sido creados con la versión de 2005 que incluyen Dundas, éstos se convertirán sin problemas siempre y cuando las versiones de 2008 estén instaladas y los informes no incluyan funcionalidad no admitida como por ejemplo código personalizado.  La siguiente lista describe la funcionalidad no admitida que no se actualizará a 2008:

           Gráficos de Dundas:

          Anotaciones

          Elementos de leyenda personalizados

          Atributos personalizados con lo siguiente:

           CUSTOM_CODE_CS

           CUSTOM_CODE_VB

           CUSTOM_CODE_COMPILED_ASSEMBLY

     

           Medidores de Dundas 2005

          Indicadores numéricos

          Indicadores de estado

          Imágenes personalizadas

     

    4.       El asesor de actualizaciones (Upgrade Advisor)

    Antes de realizar la migración, es una buena idea ejecutar el asesor de actualizaciones (Upgrade Advisor) Herramienta que analiza los componentes instalados de las versiones anteriores de SQL Server y genera un informe con los problemas que han de solucionarse antes o después de la actualización.

    Usar el Asesor de actualizaciones para preparar las actualizaciones

    http://msdn.microsoft.com/es-es/library/ms144256.aspx

     

     

    5.       Enlaces con pasos a seguir para hacer la migración o la actualización a Reporting Services 2008

     

    Cómo actualizar a SQL Server 2008 (programa de instalación)

    http://msdn.microsoft.com/es-es/library/ms144267.aspx

    Cómo migrar una instalación de Reporting Services

    http://msdn.microsoft.com/es-es/library/ms143724.aspx

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

Page 1 of 9 (81 items) 12345»