SQL Server Cambio de Nombre del Servidor
Acabo de cambiar el nombre del servidor que tiene mis bases de datos SQL.
¿Dónde debo cambiar el nombre para que no me envíe errores SQL?.
En Oracle lo haces en el *names. Ora, ¿aquí en donde?
¿Dónde debo cambiar el nombre para que no me envíe errores SQL?.
En Oracle lo haces en el *names. Ora, ¿aquí en donde?
1 respuesta
Respuesta de denciso
1
Sugiero que valides los dsns de acceso a tu servidor, ya que es la forma en la que te conectas, pero también es validar las aplicaciones que utilizan tu servidor.
Después de cambiar el nombre, todo funciona, excepto los DTS que tienen querys, me dice que el server por no esta configurado en el Data Access.
¿Qué puedo hacer en este caso?
¿Qué puedo hacer en este caso?
Haber si lo que encontré en la ayuda te ayuda:
Cambiar el nombre de un servidor
¿Cuándo cambia el nombre del equipo que ejecuta Microsoft® SQL Server? 2000, el nuevo nombre se reconoce durante el inicio de SQL Server. No tiene que ejecutar el programa de instalación de nuevo para restablecer el nombre del equipo.
Puede conectarse a SQL Server con el nuevo nombre del equipo después de haber reiniciado el servidor. No obstante, para corregir la tabla del sistema sysservers, debe ejecutar manualmente estos procedimientos:
sp_dropserver <old_name>
go
sp_addserver <new_name>
Go
Problemas con los inicios de sesión remotos y la duplicación
Si el equipo tiene inicios de sesión remotos, por ejemplo, si se trata de un publicador o un distribuidor de duplicación, sp_dropserver puede generar un error similar al siguiente:
Server:Servidor: Msg 15190, Level 16, State 1, Procedure sp_dropserver, Line 44
There are still remote logins for the server 'SERVER1'.There are still remote logins for the server 'SERVER1'.
Para solucionar el error, es posible que necesite quitar los inicios de sesión remotos para este servidor. Si la duplicación está instalada, desactívela en el servidor antes de ejecutar el procedimiento almacenado sp_dropserver.
Para desactivar la duplicación utilizando el Administrador corporativo de SQL Server
Expanda un grupo de servidores y, a continuación, expanda el distribuidor (el servidor que contiene la base de datos de distribución).
Haga clic con el botón secundario del mouse (ratón) en la carpeta REPLICATION y, a continuación, haga clic en Deshabilitar publicación.
Siga todos los pasos del Asistente para deshabilitar publicar y distribuir.
©1988-2000 Microsoft Corporation. Reservados todos los derechos.
Consideraciones acerca de la conversión y transformación de datos
Antes de utilizar Servicios de transformación de datos (DTS) para convertir o transformar datos entre datos y destinos heterogéneos, tenga en cuenta estas variaciones en la forma en que los diferentes programas, proveedores y controladores admiten los tipos de datos y las instrucciones SQL.
¿Cuándo utilice Microsoft® SQL Server? Como origen de datos, considere lo siguiente:
La transformación del tipo de datos real en el tipo de datos int puede no devolver el valor exacto, porque SQL Server 2000 sólo admite seis dígitos de precisión para el tipo de datos real. Por ejemplo, el número real 2147480000 puede dar el valor int 2147480065.
Al transformar una columna string (DBTYPE_WSTR) en date (DBTYPE_DATE) o time (DBTYPE_TIME) desde un archivo de texto, el componente de servicio de conversión de datos OLE DB sólo aceptará un formato de fecha u hora (aaaa-mm-dd hh:mm:ss. Fffffffff). Utilice la transformación de cadena de fecha y hora o bien codifique una transformación de secuencia de comandos Microsoft ActiveX® mediante la función Cdate, para transformar correctamente las fechas.
SQL Server 2000 no admite los tipos DBTYPE_DATE o DBTYPE_TIME de OLE DB. SQL Server 2000 sólo admite DBTYPE_DATETIME.
Para tener acceso a los datos en varios pasos, evite el uso de una tabla temp durante las transformaciones. En su lugar, utilice una tabla temp global o cree una tabla permanente en tempdb.
Los procedimientos almacenados que devuelven filas de las tablas temp no pueden utilizarse como origen de una transformación. Puede utilizar procedimientos almacenados que devuelvan filas de una tabla temp global o de una tabla.
Cuando utilice tablas temporales en la tarea Transformar datos, la tarea de consulta controlada por datos o la tarea de ejecución SQL en el Diseñador DTS, tenga en cuenta que no es posible utilizar una instrucción Transact-SQL o un procedimiento almacenado que llame a una tabla temp como origen.
Esta limitación no se aplica fuera del Diseñador DTS. Puede utilizar procedimientos almacenados o instrucciones de origen que tengan acceso a tablas temp de SQL Server mediante programación.
El Asistente para importación/exportación con DTS y el Diseñador DTS
Cuando utilice el Asistente para importación/exportación con DTS y el Diseñador DTS para crear paquetes, considere lo siguiente:
La interfaz de usuario de DTS permite compartir las conexiones existentes entre tareas, pero la misma conexión no puede utilizarse a la vez para el origen y el destino de una transformación.
Si utiliza el Diseñador DTS o el Asistente para importación/exportación con DTS, es posible especificar un estado de sólo lectura o en uso para algunos proveedores (por ejemplo, Microsoft Access y DSN de ODBC) que sólo sirven como orígenes de datos. Haga clic en Avanzadas en el cuadro de diálogo Propiedades de conexión y, en el cuadro de diálogo Propiedades avanzadas de conexión, establezca el valor de la propiedad de modo en 1.
Al crear una tabla con el Asistente para importación/exportación con DTS o con el Diseñador DTS, el propietario de la tabla creada en el destino es el usuario actual (generalmente dbo), independientemente de quién sea el propietario en el origen. Esto puede provocar una situación en la que el dbo intente crear en el destino una tabla con un nombre que ya existe, con lo que el intento fracasa.
Al definir una consulta controlada por datos con el Diseñador DTS, el destino de datos debe ser compatible con la interfaz ICommand de OLE DB. Debido a esta restricción, no se admiten destinos tales como archivos de texto.
La tarea Copiar objetos de SQL Server de DTS trunca los campos de tipo text, ntext e image si superan los 8388602 de longitud. El Diseñador DTS y el Asistente para importación/exportación con DTS no muestran mensajes de error. Indican que la tarea se ha completado correctamente.
La única indicación de error es un mensaje de registro que se escribe en un archivo de registro denominado <SERVIDOR>. <BASE DE DATOS>.LOG, en el Directorio de archivos de comandos especificado en la ficha Copiar del cuadro de diálogo Propiedades de la tarea Copiar objetos de SQL Server. El mensaje de registro especifica la tabla y la columna, pero no la fila, donde se ha producido el truncamiento. No se escribe ningún registro de errores en el archivo de errores DTS ni en el registro de SQL Server.
Microsoft SNA Server
Cuando utilice Microsoft SNA Server como origen de datos, considere lo siguiente:
El Proveedor Microsoft OLE DB para AS/400 y VSAM no admite las instrucciones SQL que el Asistente para importación/exportación con DTS utiliza para crear o truncar una tabla.
Microsoft Access
Cuando trabaje con Access, tenga en cuenta lo siguiente:
Cuando se exportan datos de SQL Server 2000 a Microsoft Access 97 o versiones anteriores, el Proveedor Microsoft OLE DB para Access almacena en el búfer todas las inserciones en memoria y sólo las confirma cuando el Asistente para importación/exportación con DTS termina la operación. Como resultado, al exportar tablas grandes puede presentarse una situación de escasez de memoria. Sin embargo, puede resolver este problema si construye instrucciones SELECT que envíen cantidades más pequeñas de filas en varios barridos.
Microsoft Visual FoxPro
Microsoft Visual FoxPro® sólo admite una precisión de (15,9) en los tipos de datos numeric. Los datos exportados a Visual FoxPro que excedan esta precisión se truncan y redondean.
Visual FoxPro no admite la instrucción SELECT INTO.
El Diseñador de consultas DTS admite la instrucción INSERT VALUE de Visual FoxPro, pero no la instrucción INSERT con una instrucción SELECT.
El controlador Microsoft OLE DB para ODBC no puede escribir datos BLOB en Visual FoxPro con el controlador ODBC para FoxPro, ya que Visual FoxPro no admite cursores dinámicos.
ODBC
Cuando se conecte a un origen de datos ODBC, considere lo siguiente:
El Proveedor Microsoft OLE DB para ODBC requiere una clave única en todas las tablas de destino con una columna de datos BLOB cuando se realizan operaciones de exportación.
Al utilizar el Proveedor Microsoft OLE DB para ODBC con el controlador ODBC de SQL Server, todas las columnas BLOB deberían organizarse después de las columnas de otros tipos de datos en un conjunto de filas de origen. Puede utilizar la instrucción SELECT para volver a organizar las columnas BLOB al final del conjunto de filas de destino. El Asistente para importación/exportación con DTS realiza esta operación automáticamente.
Importante Cuando utilice el Proveedor Microsoft OLE DB para ODBC con el controlador ODBC de SQL Server, los intentos de obtener una vista previa de los procedimientos almacenados producirán un error de conexión ocupada. Este problema no se produce si se utiliza el Proveedor Microsoft OLE DB para SQL Server.
Si varios subprocesos comparten un controlador Microsoft ODBC para una conexión de SQL Server, la conexión puede producir un error y devolver el mensaje de error "Conexión ocupada con resultados de otro hstmt". En algunos casos, esto afecta a los paquetes generados con el Asistente para importación/exportación con DTS. Para solucionar este problema, utilice uno de los siguientes procedimientos:
Establezca la propiedad MaxConcurrentSteps en 1 para eliminar los subprocesos que entran en conflicto.
Cree conexiones ODBC adicionales para eliminar el uso compartido de conexiones.
Utilice el proveedor OLE DB para SQL Server de Microsoft (SQLOLEDB) para conectarse a la base de datos. Si necesita conectarse a una base de datos de SQL Server 6.5, ejecute Instcatl.sql para habilitar el acceso con el proveedor OLE DB para SQL Server de Microsoft.
Oracle
Cuando utilice Oracle como origen de datos, considere lo siguiente:
Los controladores Microsoft ODBC y OLEDB para Oracle admiten los tipos de datos BLOB de Oracle 7.3, no los tipos de datos de Oracle 8.0. Por ejemplo, no admite BLOB, CLOB, NCLOB ni BFILE.
El controlador ODBC para Oracle de Microsoft no admite el envío de cadenas Unicode a un servidor Oracle. Oracle requiere que se agregue el prefijo N a las cadenas Unicode.
El controlador ODBC para Oracle de Microsoft no admite el ajuste negativo para el tipo de datos number de Oracle.
El controlador ODBC para Oracle de Microsoft informa que el tipo de datos number de Oracle sin especificarse una precisión tiene un tamaño de 20 dígitos. Al importar desde Oracle (independientemente del destino), cuando hay más de 20 dígitos, puede ser necesario incrementar manualmente la precisión si la tabla de destino no existe ya.
Oracle sólo admite una columna de datos LONG (BLOB) en una tabla.
No es posible importar o exportar columnas Oracle con nombres en minúsculas o con mezcla de mayúsculas y minúsculas. Tampoco es posible utilizar el Asistente para importación/exportación con DTS para transformar o copiar datos con nombres de columna de Oracle que contengan espacios. Oracle requiere que los nombres de columna en los que se distinga entre mayúsculas y minúsculas se especifiquen con precisión y se escriban entre comillas.
Para realizar transacciones distribuidas entre SQL Server 2000 y Oracle, debe utilizar Oracle versión 8.0.4.1 o posterior. Para obtener más información, consulte Transacciones distribuidas.
Dado que el Proveedor Microsoft OLE DB para Oracle no admite ICommandWithParameters, no es posible utilizarlo como destino de una tarea de consulta controlada por datos. Cuando se utiliza este proveedor en el Diseñador DTS, los botones Parámetros de la tarea Transformar datos, la tarea de consulta controlada por datos y la tarea de ejecución SQL se inhabilitan.
DB2 en IBM AS/400
Cuando se conecte a un origen de datos DB2, considere lo siguiente:
No existe compatibilidad con Unicode o BLOB en los sistemas AS/400.
No se puede transformar ninguna tabla con un valor de columna NULL en un servidor AS/400, porque este sistema no admite la sintaxis de NULL en la instrucción CREATE TABLE. Sin embargo, puede enviar valores NULL si modifica la sintaxis de CREATE TABLE para quitar las referencias a NULL. AS/400 no admite NOT NULL; cuando no se especifica, se supone que el valor es NULL.
Utilizar el controlador ODBC para Sybase
Cuando se conecte a un origen de datos Sybase ODBC, considere lo siguiente:
Cuando transforme datos de SQL Server a la versión 11 de Sybase mediante el Asistente para importación/exportación con DTS:
El tipo de datos numeric (3,0) de SQL Server se asigna al tipo de datos smallmoney de Sybase de manera predeterminada. Cambie esta configuración para evitar pérdidas de datos.
El tipo de datos numeric (18, por o 19, x) de SQL Server se asigna al tipo de datos money de Sybase de manera predeterminada. Cambie esta configuración para evitar pérdidas de datos.
Cuando se mueven los datos a una nueva tabla de Sybase, si hace clic en Aceptar en el cuadro de diálogo Asignaciones y transformaciones de columnas, el asistente devolverá el mensaje de error "La tabla ya existe". Debe pasar por alto este mensaje.
No es posible quitar y volver a crear una tabla de Sybase con el Asistente para importación/exportación con DTS. Debe realizar esta acción sin utilizar un asistente.
El Diseñador de consultas DTS no admite la instrucción SQLAnywhere CREATE TABLE de Sybase.
El Asistente para importación/exportación con DTS sólo puede mover una tabla cada vez a una base de datos SQLAnywhere debido a una limitación del controlador SQLAnywhere. Puede superar esta limitación si utiliza el Diseñador DTS. Sin embargo, deberá establecer la propiedad ExecuteInMainThread del objeto Step como True para cada tabla, puesto que el controlador SQLAnywhere no garantiza la seguridad de los subprocesos.
No es posible copiar una tabla a un destino Sybase que contenga una columna BLOB.
Si copia mediante programación desde Sybase una tabla que contiene el tipo de datos image, el cambio de la configuración BLOB predeterminada puede provocar un error.
DBase y Paradox
Cuando se conecte a un origen de datos dBase y Paradox, considere lo siguiente:
En dBase y Paradox, los nombres de tabla están limitados a ocho caracteres. En dBase, los nombres de columna están limitados a 10 caracteres.
Importar o exportar archivos
Cuando importe o exporte datos de archivos de texto, considere lo siguiente:
Si importa o exporta columnas de tipo char o varchar, es posible que algunos caracteres extendidos no se copien correctamente si la página de códigos OEM del cliente es distinta de la del servidor. Al importar o exportar datos de columnas nchar o nvarchar, todos los caracteres se copian correctamente.
Si exporta columnas BLOB (incluyendo los tipos de datos text y ntext de SQL Server) a un campo de texto de longitud fija, la longitud predeterminada será igual a la longitud máxima del campo BLOB (dos gigabytes aproximadamente). Para evitar el desbordamiento del disco, elija una longitud de campo más pequeña pero adecuada o bien utilice un formato delimitado, si es posible.
El proveedor OLE DB para archivos de texto que se utiliza en DTS no puede procesar columnas con datos BLOB de más de dos megabytes (MB).
Problemas relacionados con las páginas de códigos, la intercalación y los datos que no son Unicode
Cuando se utilice DTS para copiar datos entre bases de datos de SQL Server con páginas de códigos e intercalaciones diferentes, puede que se pierdan datos o que se traduzcan de forma incorrecta.
Para evitar problemas de traducción, almacene los datos internacionales en formato Unicode. Una vez convertidos a Unicode, podrá transferir fácilmente los datos con cualquier intercalación o página de códigos, sin sufrir pérdidas ni errores de traducción, a cualquier base de datos de Microsoft SQL Server 2000 o Microsoft SQL Server 7.0.
En Microsoft SQL Server 2000, las intercalaciones se asocian a páginas de códigos en particular y se asignan a columnas individuales. (Microsoft SQL Server 7.0 utiliza una sola página de códigos predeterminada y no admite intercalaciones de nivel de columna). Si las páginas de códigos utilizada para una columna de origen y una columna de destino coinciden, las columnas que no son Unicode no sufren pérdidas de datos. Cuando se copian datos entre columnas que no son Unicode y las páginas de códigos de origen y de destino no coinciden, pueden producirse pérdidas de datos. En algunos casos, DTS ejecutará una asignación basada en el mejor ajuste, en la que pueden perderse datos si el origen contiene caracteres que no se encuentran en la página de códigos de destino. En otros casos, DTS ejecuta una copia sin que intervenga ninguna traducción, lo que dará como resultado la pérdida de los datos que no estén representados por los mismos valores binarios en ambas páginas de códigos. A continuación se exponen problemas y directrices para utilizar la tarea Copiar objetos de SQL Server y que tienen al copiar datos con la transformación Copiar columna utilizando diferentes intercalaciones o páginas de códigos.
Tarea Copiar objetos de SQL Server
Lo siguiente se refiere al modo en que la tarea Copiar objetos de SQL Server controla los datos que no son Unicode:
Cuando copie datos desde una instancia de SQL Server 2000 a otra instancia de SQL Server 2000 no habrá ninguna pérdida de datos, siempre que se haya establecido la propiedad UseCollation de la tarea Copiar objetos de SQL Server.
Cuando copie datos desde una instancia de SQL Server 2000 a SQL Server 7.0, se utilizará una asignación basada en el mejor ajuste para las columnas que tengan intercalaciones que coincidan con la página de códigos de intercalación predeterminada de la base de datos. Los datos almacenados en una columna que tengan una página de códigos diferente se tratarán como si estuvieran codificados con la página de códigos predeterminada, con las consiguientes pérdidas debidas a la traducción.
Cuando copie datos desde SQL Server 7.0 a una instancia de SQL Server 2000, la propiedad UseCollation no estará disponible porque SQL Server 7.0 no puede determinar a cuál de las diferentes intercalaciones se asigna su página de códigos predeterminada. Durante la ejecución de la tarea Copiar objetos de SQL Server no se admite ninguna intercalación; en consecuencia, a las columnas de destino que no son Unicode se les asignará la intercalación predeterminada para la base de datos de destino. Si la página de códigos que se asocia a la intercalación no coincide con la de la base de datos de origen, DTS ejecutará una asignación basada en el mejor ajuste
Cuando copie datos de SQL Server 7.0 a SQL Server 7.0, si las bases de datos de origen y de destino utilizan páginas de códigos predeterminadas diferentes, DTS ejecutará una asignación basada en el mejor ajuste.
Si desea asegurarse de que no se producen pérdidas de datos al copiar datos que no son Unicode, puede utilizar la característica de copia masiva de SQL Server para exportar los datos en formato Unicode y, a continuación, utilizar la copia masiva o DTS para importarlos.
Para deshabilitar la secuencia de comandos predeterminada de las intercalaciones, agregue código o utilice la opción Modificar sin conexión o bien la tarea Propiedades dinámicas para agregar el valor de SQLDMOScript2_70Only a la propiedad ScriptOptionEx de la tarea Copiar objetos de SQL Server.
Transformación Copiar columna
Lo siguiente se refiere al modo en que la transformación Copiar columna controla los datos que no son Unicode entre diferentes páginas de códigos:
Si la columna de origen es Unicode y la columna de destino no es Unicode, se realiza una asignación basada en el mejor ajuste y se intenta traducir los datos entre el origen y el destino.
Si la columna de origen no es Unicode y la de destino sí lo es, DTS interpreta que la columna de origen pertenece a la página de códigos 1252, con independencia de la página de códigos que se utilice realmente.
Si la columna de origen y la columna de destino no son Unicode, los datos sin formato se copiarán sin traducción y se producirán algunas pérdidas de datos.
©1988-2000 Microsoft Corporation. Reservados todos los derechos.
Según los comentarios de otras personas, tendrás que volver a generarlos porque se pierde la liga.
Cambiar el nombre de un servidor
¿Cuándo cambia el nombre del equipo que ejecuta Microsoft® SQL Server? 2000, el nuevo nombre se reconoce durante el inicio de SQL Server. No tiene que ejecutar el programa de instalación de nuevo para restablecer el nombre del equipo.
Puede conectarse a SQL Server con el nuevo nombre del equipo después de haber reiniciado el servidor. No obstante, para corregir la tabla del sistema sysservers, debe ejecutar manualmente estos procedimientos:
sp_dropserver <old_name>
go
sp_addserver <new_name>
Go
Problemas con los inicios de sesión remotos y la duplicación
Si el equipo tiene inicios de sesión remotos, por ejemplo, si se trata de un publicador o un distribuidor de duplicación, sp_dropserver puede generar un error similar al siguiente:
Server:Servidor: Msg 15190, Level 16, State 1, Procedure sp_dropserver, Line 44
There are still remote logins for the server 'SERVER1'.There are still remote logins for the server 'SERVER1'.
Para solucionar el error, es posible que necesite quitar los inicios de sesión remotos para este servidor. Si la duplicación está instalada, desactívela en el servidor antes de ejecutar el procedimiento almacenado sp_dropserver.
Para desactivar la duplicación utilizando el Administrador corporativo de SQL Server
Expanda un grupo de servidores y, a continuación, expanda el distribuidor (el servidor que contiene la base de datos de distribución).
Haga clic con el botón secundario del mouse (ratón) en la carpeta REPLICATION y, a continuación, haga clic en Deshabilitar publicación.
Siga todos los pasos del Asistente para deshabilitar publicar y distribuir.
©1988-2000 Microsoft Corporation. Reservados todos los derechos.
Consideraciones acerca de la conversión y transformación de datos
Antes de utilizar Servicios de transformación de datos (DTS) para convertir o transformar datos entre datos y destinos heterogéneos, tenga en cuenta estas variaciones en la forma en que los diferentes programas, proveedores y controladores admiten los tipos de datos y las instrucciones SQL.
¿Cuándo utilice Microsoft® SQL Server? Como origen de datos, considere lo siguiente:
La transformación del tipo de datos real en el tipo de datos int puede no devolver el valor exacto, porque SQL Server 2000 sólo admite seis dígitos de precisión para el tipo de datos real. Por ejemplo, el número real 2147480000 puede dar el valor int 2147480065.
Al transformar una columna string (DBTYPE_WSTR) en date (DBTYPE_DATE) o time (DBTYPE_TIME) desde un archivo de texto, el componente de servicio de conversión de datos OLE DB sólo aceptará un formato de fecha u hora (aaaa-mm-dd hh:mm:ss. Fffffffff). Utilice la transformación de cadena de fecha y hora o bien codifique una transformación de secuencia de comandos Microsoft ActiveX® mediante la función Cdate, para transformar correctamente las fechas.
SQL Server 2000 no admite los tipos DBTYPE_DATE o DBTYPE_TIME de OLE DB. SQL Server 2000 sólo admite DBTYPE_DATETIME.
Para tener acceso a los datos en varios pasos, evite el uso de una tabla temp durante las transformaciones. En su lugar, utilice una tabla temp global o cree una tabla permanente en tempdb.
Los procedimientos almacenados que devuelven filas de las tablas temp no pueden utilizarse como origen de una transformación. Puede utilizar procedimientos almacenados que devuelvan filas de una tabla temp global o de una tabla.
Cuando utilice tablas temporales en la tarea Transformar datos, la tarea de consulta controlada por datos o la tarea de ejecución SQL en el Diseñador DTS, tenga en cuenta que no es posible utilizar una instrucción Transact-SQL o un procedimiento almacenado que llame a una tabla temp como origen.
Esta limitación no se aplica fuera del Diseñador DTS. Puede utilizar procedimientos almacenados o instrucciones de origen que tengan acceso a tablas temp de SQL Server mediante programación.
El Asistente para importación/exportación con DTS y el Diseñador DTS
Cuando utilice el Asistente para importación/exportación con DTS y el Diseñador DTS para crear paquetes, considere lo siguiente:
La interfaz de usuario de DTS permite compartir las conexiones existentes entre tareas, pero la misma conexión no puede utilizarse a la vez para el origen y el destino de una transformación.
Si utiliza el Diseñador DTS o el Asistente para importación/exportación con DTS, es posible especificar un estado de sólo lectura o en uso para algunos proveedores (por ejemplo, Microsoft Access y DSN de ODBC) que sólo sirven como orígenes de datos. Haga clic en Avanzadas en el cuadro de diálogo Propiedades de conexión y, en el cuadro de diálogo Propiedades avanzadas de conexión, establezca el valor de la propiedad de modo en 1.
Al crear una tabla con el Asistente para importación/exportación con DTS o con el Diseñador DTS, el propietario de la tabla creada en el destino es el usuario actual (generalmente dbo), independientemente de quién sea el propietario en el origen. Esto puede provocar una situación en la que el dbo intente crear en el destino una tabla con un nombre que ya existe, con lo que el intento fracasa.
Al definir una consulta controlada por datos con el Diseñador DTS, el destino de datos debe ser compatible con la interfaz ICommand de OLE DB. Debido a esta restricción, no se admiten destinos tales como archivos de texto.
La tarea Copiar objetos de SQL Server de DTS trunca los campos de tipo text, ntext e image si superan los 8388602 de longitud. El Diseñador DTS y el Asistente para importación/exportación con DTS no muestran mensajes de error. Indican que la tarea se ha completado correctamente.
La única indicación de error es un mensaje de registro que se escribe en un archivo de registro denominado <SERVIDOR>. <BASE DE DATOS>.LOG, en el Directorio de archivos de comandos especificado en la ficha Copiar del cuadro de diálogo Propiedades de la tarea Copiar objetos de SQL Server. El mensaje de registro especifica la tabla y la columna, pero no la fila, donde se ha producido el truncamiento. No se escribe ningún registro de errores en el archivo de errores DTS ni en el registro de SQL Server.
Microsoft SNA Server
Cuando utilice Microsoft SNA Server como origen de datos, considere lo siguiente:
El Proveedor Microsoft OLE DB para AS/400 y VSAM no admite las instrucciones SQL que el Asistente para importación/exportación con DTS utiliza para crear o truncar una tabla.
Microsoft Access
Cuando trabaje con Access, tenga en cuenta lo siguiente:
Cuando se exportan datos de SQL Server 2000 a Microsoft Access 97 o versiones anteriores, el Proveedor Microsoft OLE DB para Access almacena en el búfer todas las inserciones en memoria y sólo las confirma cuando el Asistente para importación/exportación con DTS termina la operación. Como resultado, al exportar tablas grandes puede presentarse una situación de escasez de memoria. Sin embargo, puede resolver este problema si construye instrucciones SELECT que envíen cantidades más pequeñas de filas en varios barridos.
Microsoft Visual FoxPro
Microsoft Visual FoxPro® sólo admite una precisión de (15,9) en los tipos de datos numeric. Los datos exportados a Visual FoxPro que excedan esta precisión se truncan y redondean.
Visual FoxPro no admite la instrucción SELECT INTO.
El Diseñador de consultas DTS admite la instrucción INSERT VALUE de Visual FoxPro, pero no la instrucción INSERT con una instrucción SELECT.
El controlador Microsoft OLE DB para ODBC no puede escribir datos BLOB en Visual FoxPro con el controlador ODBC para FoxPro, ya que Visual FoxPro no admite cursores dinámicos.
ODBC
Cuando se conecte a un origen de datos ODBC, considere lo siguiente:
El Proveedor Microsoft OLE DB para ODBC requiere una clave única en todas las tablas de destino con una columna de datos BLOB cuando se realizan operaciones de exportación.
Al utilizar el Proveedor Microsoft OLE DB para ODBC con el controlador ODBC de SQL Server, todas las columnas BLOB deberían organizarse después de las columnas de otros tipos de datos en un conjunto de filas de origen. Puede utilizar la instrucción SELECT para volver a organizar las columnas BLOB al final del conjunto de filas de destino. El Asistente para importación/exportación con DTS realiza esta operación automáticamente.
Importante Cuando utilice el Proveedor Microsoft OLE DB para ODBC con el controlador ODBC de SQL Server, los intentos de obtener una vista previa de los procedimientos almacenados producirán un error de conexión ocupada. Este problema no se produce si se utiliza el Proveedor Microsoft OLE DB para SQL Server.
Si varios subprocesos comparten un controlador Microsoft ODBC para una conexión de SQL Server, la conexión puede producir un error y devolver el mensaje de error "Conexión ocupada con resultados de otro hstmt". En algunos casos, esto afecta a los paquetes generados con el Asistente para importación/exportación con DTS. Para solucionar este problema, utilice uno de los siguientes procedimientos:
Establezca la propiedad MaxConcurrentSteps en 1 para eliminar los subprocesos que entran en conflicto.
Cree conexiones ODBC adicionales para eliminar el uso compartido de conexiones.
Utilice el proveedor OLE DB para SQL Server de Microsoft (SQLOLEDB) para conectarse a la base de datos. Si necesita conectarse a una base de datos de SQL Server 6.5, ejecute Instcatl.sql para habilitar el acceso con el proveedor OLE DB para SQL Server de Microsoft.
Oracle
Cuando utilice Oracle como origen de datos, considere lo siguiente:
Los controladores Microsoft ODBC y OLEDB para Oracle admiten los tipos de datos BLOB de Oracle 7.3, no los tipos de datos de Oracle 8.0. Por ejemplo, no admite BLOB, CLOB, NCLOB ni BFILE.
El controlador ODBC para Oracle de Microsoft no admite el envío de cadenas Unicode a un servidor Oracle. Oracle requiere que se agregue el prefijo N a las cadenas Unicode.
El controlador ODBC para Oracle de Microsoft no admite el ajuste negativo para el tipo de datos number de Oracle.
El controlador ODBC para Oracle de Microsoft informa que el tipo de datos number de Oracle sin especificarse una precisión tiene un tamaño de 20 dígitos. Al importar desde Oracle (independientemente del destino), cuando hay más de 20 dígitos, puede ser necesario incrementar manualmente la precisión si la tabla de destino no existe ya.
Oracle sólo admite una columna de datos LONG (BLOB) en una tabla.
No es posible importar o exportar columnas Oracle con nombres en minúsculas o con mezcla de mayúsculas y minúsculas. Tampoco es posible utilizar el Asistente para importación/exportación con DTS para transformar o copiar datos con nombres de columna de Oracle que contengan espacios. Oracle requiere que los nombres de columna en los que se distinga entre mayúsculas y minúsculas se especifiquen con precisión y se escriban entre comillas.
Para realizar transacciones distribuidas entre SQL Server 2000 y Oracle, debe utilizar Oracle versión 8.0.4.1 o posterior. Para obtener más información, consulte Transacciones distribuidas.
Dado que el Proveedor Microsoft OLE DB para Oracle no admite ICommandWithParameters, no es posible utilizarlo como destino de una tarea de consulta controlada por datos. Cuando se utiliza este proveedor en el Diseñador DTS, los botones Parámetros de la tarea Transformar datos, la tarea de consulta controlada por datos y la tarea de ejecución SQL se inhabilitan.
DB2 en IBM AS/400
Cuando se conecte a un origen de datos DB2, considere lo siguiente:
No existe compatibilidad con Unicode o BLOB en los sistemas AS/400.
No se puede transformar ninguna tabla con un valor de columna NULL en un servidor AS/400, porque este sistema no admite la sintaxis de NULL en la instrucción CREATE TABLE. Sin embargo, puede enviar valores NULL si modifica la sintaxis de CREATE TABLE para quitar las referencias a NULL. AS/400 no admite NOT NULL; cuando no se especifica, se supone que el valor es NULL.
Utilizar el controlador ODBC para Sybase
Cuando se conecte a un origen de datos Sybase ODBC, considere lo siguiente:
Cuando transforme datos de SQL Server a la versión 11 de Sybase mediante el Asistente para importación/exportación con DTS:
El tipo de datos numeric (3,0) de SQL Server se asigna al tipo de datos smallmoney de Sybase de manera predeterminada. Cambie esta configuración para evitar pérdidas de datos.
El tipo de datos numeric (18, por o 19, x) de SQL Server se asigna al tipo de datos money de Sybase de manera predeterminada. Cambie esta configuración para evitar pérdidas de datos.
Cuando se mueven los datos a una nueva tabla de Sybase, si hace clic en Aceptar en el cuadro de diálogo Asignaciones y transformaciones de columnas, el asistente devolverá el mensaje de error "La tabla ya existe". Debe pasar por alto este mensaje.
No es posible quitar y volver a crear una tabla de Sybase con el Asistente para importación/exportación con DTS. Debe realizar esta acción sin utilizar un asistente.
El Diseñador de consultas DTS no admite la instrucción SQLAnywhere CREATE TABLE de Sybase.
El Asistente para importación/exportación con DTS sólo puede mover una tabla cada vez a una base de datos SQLAnywhere debido a una limitación del controlador SQLAnywhere. Puede superar esta limitación si utiliza el Diseñador DTS. Sin embargo, deberá establecer la propiedad ExecuteInMainThread del objeto Step como True para cada tabla, puesto que el controlador SQLAnywhere no garantiza la seguridad de los subprocesos.
No es posible copiar una tabla a un destino Sybase que contenga una columna BLOB.
Si copia mediante programación desde Sybase una tabla que contiene el tipo de datos image, el cambio de la configuración BLOB predeterminada puede provocar un error.
DBase y Paradox
Cuando se conecte a un origen de datos dBase y Paradox, considere lo siguiente:
En dBase y Paradox, los nombres de tabla están limitados a ocho caracteres. En dBase, los nombres de columna están limitados a 10 caracteres.
Importar o exportar archivos
Cuando importe o exporte datos de archivos de texto, considere lo siguiente:
Si importa o exporta columnas de tipo char o varchar, es posible que algunos caracteres extendidos no se copien correctamente si la página de códigos OEM del cliente es distinta de la del servidor. Al importar o exportar datos de columnas nchar o nvarchar, todos los caracteres se copian correctamente.
Si exporta columnas BLOB (incluyendo los tipos de datos text y ntext de SQL Server) a un campo de texto de longitud fija, la longitud predeterminada será igual a la longitud máxima del campo BLOB (dos gigabytes aproximadamente). Para evitar el desbordamiento del disco, elija una longitud de campo más pequeña pero adecuada o bien utilice un formato delimitado, si es posible.
El proveedor OLE DB para archivos de texto que se utiliza en DTS no puede procesar columnas con datos BLOB de más de dos megabytes (MB).
Problemas relacionados con las páginas de códigos, la intercalación y los datos que no son Unicode
Cuando se utilice DTS para copiar datos entre bases de datos de SQL Server con páginas de códigos e intercalaciones diferentes, puede que se pierdan datos o que se traduzcan de forma incorrecta.
Para evitar problemas de traducción, almacene los datos internacionales en formato Unicode. Una vez convertidos a Unicode, podrá transferir fácilmente los datos con cualquier intercalación o página de códigos, sin sufrir pérdidas ni errores de traducción, a cualquier base de datos de Microsoft SQL Server 2000 o Microsoft SQL Server 7.0.
En Microsoft SQL Server 2000, las intercalaciones se asocian a páginas de códigos en particular y se asignan a columnas individuales. (Microsoft SQL Server 7.0 utiliza una sola página de códigos predeterminada y no admite intercalaciones de nivel de columna). Si las páginas de códigos utilizada para una columna de origen y una columna de destino coinciden, las columnas que no son Unicode no sufren pérdidas de datos. Cuando se copian datos entre columnas que no son Unicode y las páginas de códigos de origen y de destino no coinciden, pueden producirse pérdidas de datos. En algunos casos, DTS ejecutará una asignación basada en el mejor ajuste, en la que pueden perderse datos si el origen contiene caracteres que no se encuentran en la página de códigos de destino. En otros casos, DTS ejecuta una copia sin que intervenga ninguna traducción, lo que dará como resultado la pérdida de los datos que no estén representados por los mismos valores binarios en ambas páginas de códigos. A continuación se exponen problemas y directrices para utilizar la tarea Copiar objetos de SQL Server y que tienen al copiar datos con la transformación Copiar columna utilizando diferentes intercalaciones o páginas de códigos.
Tarea Copiar objetos de SQL Server
Lo siguiente se refiere al modo en que la tarea Copiar objetos de SQL Server controla los datos que no son Unicode:
Cuando copie datos desde una instancia de SQL Server 2000 a otra instancia de SQL Server 2000 no habrá ninguna pérdida de datos, siempre que se haya establecido la propiedad UseCollation de la tarea Copiar objetos de SQL Server.
Cuando copie datos desde una instancia de SQL Server 2000 a SQL Server 7.0, se utilizará una asignación basada en el mejor ajuste para las columnas que tengan intercalaciones que coincidan con la página de códigos de intercalación predeterminada de la base de datos. Los datos almacenados en una columna que tengan una página de códigos diferente se tratarán como si estuvieran codificados con la página de códigos predeterminada, con las consiguientes pérdidas debidas a la traducción.
Cuando copie datos desde SQL Server 7.0 a una instancia de SQL Server 2000, la propiedad UseCollation no estará disponible porque SQL Server 7.0 no puede determinar a cuál de las diferentes intercalaciones se asigna su página de códigos predeterminada. Durante la ejecución de la tarea Copiar objetos de SQL Server no se admite ninguna intercalación; en consecuencia, a las columnas de destino que no son Unicode se les asignará la intercalación predeterminada para la base de datos de destino. Si la página de códigos que se asocia a la intercalación no coincide con la de la base de datos de origen, DTS ejecutará una asignación basada en el mejor ajuste
Cuando copie datos de SQL Server 7.0 a SQL Server 7.0, si las bases de datos de origen y de destino utilizan páginas de códigos predeterminadas diferentes, DTS ejecutará una asignación basada en el mejor ajuste.
Si desea asegurarse de que no se producen pérdidas de datos al copiar datos que no son Unicode, puede utilizar la característica de copia masiva de SQL Server para exportar los datos en formato Unicode y, a continuación, utilizar la copia masiva o DTS para importarlos.
Para deshabilitar la secuencia de comandos predeterminada de las intercalaciones, agregue código o utilice la opción Modificar sin conexión o bien la tarea Propiedades dinámicas para agregar el valor de SQLDMOScript2_70Only a la propiedad ScriptOptionEx de la tarea Copiar objetos de SQL Server.
Transformación Copiar columna
Lo siguiente se refiere al modo en que la transformación Copiar columna controla los datos que no son Unicode entre diferentes páginas de códigos:
Si la columna de origen es Unicode y la columna de destino no es Unicode, se realiza una asignación basada en el mejor ajuste y se intenta traducir los datos entre el origen y el destino.
Si la columna de origen no es Unicode y la de destino sí lo es, DTS interpreta que la columna de origen pertenece a la página de códigos 1252, con independencia de la página de códigos que se utilice realmente.
Si la columna de origen y la columna de destino no son Unicode, los datos sin formato se copiarán sin traducción y se producirán algunas pérdidas de datos.
©1988-2000 Microsoft Corporation. Reservados todos los derechos.
Según los comentarios de otras personas, tendrás que volver a generarlos porque se pierde la liga.
Estoy ejecutando este comando
SELECT SERVERPROPERTY('MachineName'), SERVERPROPERTY ('InstanceName')
y salen diferentes, como ejecuto esta sentencia:
get current machine name and instance name
o esta:
get current SQL Server name\instance name
Muchas gracias
SELECT SERVERPROPERTY('MachineName'), SERVERPROPERTY ('InstanceName')
y salen diferentes, como ejecuto esta sentencia:
get current machine name and instance name
o esta:
get current SQL Server name\instance name
Muchas gracias
Prueba con lo siguiente:
SELECT CONVERT(char(60), SERVERPROPERTY('servername'))
SELECT CONVERT(char(60), SERVERPROPERTY('InstanceName'))
La primera regresa el nombre completo del servidor y la segunda el nombre de la instancia del servidor.
Si algo no esta bien, tienes que checar otra vez las propiedades de tu servidor.
SELECT CONVERT(char(60), SERVERPROPERTY('servername'))
SELECT CONVERT(char(60), SERVERPROPERTY('InstanceName'))
La primera regresa el nombre completo del servidor y la segunda el nombre de la instancia del servidor.
Si algo no esta bien, tienes que checar otra vez las propiedades de tu servidor.
Antes que nada muchas gracias por la ayuda.
Tengo otra pregunta .. como le quitas las horas a un campo Datetime ... como no logre hacerlo utilice el DATEPART y saque día, mes y año por separado, después quise unirlos con { fn CONCAT()} pero me envía error.
¿Alguna idea?
Mil gracias
Tengo otra pregunta .. como le quitas las horas a un campo Datetime ... como no logre hacerlo utilice el DATEPART y saque día, mes y año por separado, después quise unirlos con { fn CONCAT()} pero me envía error.
¿Alguna idea?
Mil gracias
Puedes utilizar un select convert(char(10),mifecha,107)
CAST y CONVERT
Convierten explícitamente una expresión de un tipo de datos en otro. CAST y CONVERT proporcionan funciones similares.
Sintaxis
Uso de CAST:
CAST ( expression AS data_type )
Uso de CONVERT:
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
Argumentos
Expression
¿Es cualquier expresión válida de Microsoft® SQL Server?. Para obtener más información, consulte Expresiones.
data_type
Es el tipo de datos de destino proporcionado por el sistema, incluido bigint y sql_variant. No se pueden utilizar tipos de datos definidos por el usuario. Para obtener más información acerca de los tipos de datos disponibles, consulte Tipos de datos.
length
Es un parámetro opcional de los tipos de datos nchar, nvarchar, char, varchar, binary o varbinary.
Style
Es el estilo del formato de fecha que se utiliza para convertir datos datetime o smalldatetime en datos de cadenas de caracteres (tipos de datos nchar, nvarchar, char, varchar, nchar o nvarchar), o el formato de cadena cuando se convierten datos float, real, money o smallmoney en datos de cadenas de caracteres (tipos de datos nchar, nvarchar, char, varchar, nchar o nvarchar).
SQL Server acepta el formato de fecha en estilo árabe, utilizando el algoritmo kuwaití.
En la siguiente tabla, las dos columnas de la izquierda representan los valores de style para la conversión de datetime o smalldatetime en cadenas de caracteres. Agregue 100 al valor de style para obtener el año con cuatro cifras, incluido el siglo (yyyy).
Sin el siglo
(Yy) Con el siglo
(Yyyy)
Estándar
Entrada/Salida**
- 0 o 100 (*) Valor predeterminado mon dd yyyy hh:miAM (o PM)
1 101 USA mm/dd/yy
2 102 ANSI yy.mm.dd
3 103 Británico/Francés dd/mm/yy
4 104 Alemán dd.mm.yy
5 105 Italiano dd-mm-yy
6 106 - dd mes aa
7 107 - Mes dd, aa
8 108 - hh:mm:ss
- 9 o 109 (*) Predeterminado + milisegundos mon dd yyyy hh:mi:ss:mmmAM (o PM)
10 110 USA mm-dd-yy
11 111 JAPÓN yy/mm/dd
12 112 ISO yymmdd
- 13 o 113 (*) Europeo predeterminado + milisegundos dd mon yyyy hh:mm:ss:mmm(24h)
14 114 - hh:mi:ss:mmm(24h)
- 20 o 120 (*) ODBC canónico yyyy-mm-dd hh:mi:ss(24h)
- 21 o 121 (*) ODBC canónico (con milisegundos) yyyy-mm-dd hh:mi:ss.mmm(24h)
- 126(***) ISO8601 yyyy-mm-dd Thh:mm:ss:mmm(sin espacios)
- 130* Kuwaití dd mon yyyy hh:mi:ss:mmmAM
- 131* Kuwaití dd/mm/yy hh:mi:ss:mmmAM
* Los valores predeterminados (style 0 o 100, 9 o 109, 13 o 113, 20 o 120, y 21 o 121) siempre devuelven el siglo (yyyy).
** Entrada cuando se convierte en datetime; salida cuando se convierte en cadenas de caracteres.
*** Diseñado para uso XML. Para la conversión de datos datetime o smalldatetime a character, el formato de salida es el que aparece descrito en la tabla. Para la conversión de datos float, money o smallmoney a character, la salida es equivalente a estilo 2. Para la conversión de datos real a character, la salda es equivalente a estilo 1.
Importante De forma predeterminada, SQL Server interpreta los años de dos cifras con el año 2049 como límite. Es decir, el año 49 se interpreta como 2049 y el año 50 se interpreta como 1950. Muchas aplicaciones de cliente, como las basadas en objetos de Automatización OLE, utilizan como límite el año 2030. SQL Server proporciona una opción de configuración (two digit year cutoff o reducción del año a dos dígitos) que cambia el año límite en SQL Server y permite el tratamiento coherente de las fechas. Sin embargo, el método más seguro es especificar los años con cuatro cifras.
Cuando se convierten cadenas de caracteres desde smalldatetime, los estilos que incluyen segundos o milisegundos muestran ceros en dichas posiciones. Puede recortar las partes de la fecha que no desee cuando convierta valores datetime o smalldatetime si utiliza la longitud apropiada en el tipo de datos char o varchar.
Esta tabla muestra los valores de style para la conversión de float o real en datos de cadenas de caracteres.
Valor Salida
0 (predeterminado) Seis cifras como máximo. Utiliza la notación científica cuando es apropiado.
1 Siempre ocho cifras. Utiliza siempre la notación científica.
2 Siempre 16 cifras. Utiliza siempre la notación científica.
En la siguiente tabla, la columna de la izquierda representa el valor de style para la conversión de money o smallmoney en datos de cadenas de caracteres.
Valor Salida
0 (predeterminado) Sin separadores de millar a la izquierda del separador decimal y dos cifras decimales; por ejemplo, 4235,98.
1 Separadores de millar a la izquierda del separador decimal y dos cifras decimales; por ejemplo, 3.510,92.
2 Sin separadores de millar a la izquierda del separador decimal y cuatro cifras decimales; por ejemplo, 4235,9819.
Tipos devueltos
Devuelve el mismo valor que si data type es 0.
Observaciones
Las conversiones implícitas son aquellas conversiones que ocurren sin especificar las funciones CAST o CONVERT. Las conversiones explícitas son aquellas conversiones que requieren que se especifique la función CAST (CONVERT). Este gráfico muestra todas las conversiones de tipos de datos explícitas e implícitas permitidas entre los tipos de datos del sistema de SQL Server, incluidos bigint y sql_variant.
Nota Como los datos Unicode siempre utilizan un número par de bytes, preste atención al convertir binary o varbinary en tipos de datos aceptados en Unicode, y viceversa. Por ejemplo, esta conversión no devuelve el valor hexadecimal 41, sino 4100: SELECT CAST(CAST(0x41 AS nvarchar) AS varbinary)
No se acepta la conversión automática para los tipos de datos text e image. Puede convertir explícitamente datos de tipo text en cadenas de caracteres y datos de tipo image en datos de tipo binary o varbinary, pero la longitud máxima es 8000. Si intenta una conversión incorrecta (por ejemplo, si convierte en int una expresión de cadena de caracteres que incluya letras), SQL Server genera un mensaje de error.
Si la salida de CAST o CONVERT es una cadena de caracteres y la entrada es otra cadena, la salida dispone de la misma intercalación y etiqueta de intercalación que la entrada. Si la entrada no es una cadena de caracteres, la salida tiene la intercalación predeterminada de la base de datos y una etiqueta de intercalación coaccionable-predeterminada. Para obtener más información, consulte Precedencia de intercalación.
Para asignar otra intercalación a la salida, aplique la cláusula COLLATE a la expresión de resultado de las funciones CAST o CONVERT. Por ejemplo:
SELECT CAST('abc' AS varchar(5)) COLLATE French_CS_AS
No existe una conversión implícita en la asignación del tipo de datos sql_variant, pero sí hay una conversión implícita a sql_variant.
Al convertir expresiones de caracteres o binarias (char, nchar, nvarchar, varchar, binary o varbinary) en una expresión de un tipo de datos diferente, los datos pueden quedar recortados, se pueden presentar parcialmente o se puede devolver un error porque el resultado es demasiado corto para ser presentado. Las conversiones en char, varchar, nchar, nvarchar, binary y varbinary se recortan, excepto en las conversiones que se muestran en esta tabla.
Del tipo de datos Al tipo de datos Resultado
int, smallint o tinyint char *
varchar *
nchar E
nvarchar E
money, smallmoney, numeric, decimal, float o real char E
varchar E
nchar E
nvarchar E
* Resultado demasiado corto para ser presentado.
E Error devuelto porque el resultado es demasiado corto para ser presentado.
Microsoft SQL Server garantiza que sólo las conversiones circulares, las conversiones que convierten un tipo de datos en otro y después vuelven a convertirlo en el tipo de datos original, devolverán los mismos valores en versiones diferentes. Este ejemplo muestra una conversión circular:
DECLARE @myval decimal (5, 2)
SET @myval = 193.57
SELECT CAST(CAST(@myval AS varbinary(20)) AS decimal(10,5))
-- Or, using CONVERT
SELECT CONVERT(decimal(10,5), CONVERT(varbinary(20), @myval))
No intente generar, por ejemplo, valores binary y convertirlos en un tipo de datos de la categoría de tipos de datos numéricos. SQL Server no garantiza que el resultado de una conversión de tipos de datos decimal o numeric a binary sea igual entre distintas versiones de SQL Server.
Este ejemplo muestra una expresión resultante demasiado corta para ser presentada.
USE pubs
SELECT SUBSTRING(title, 1, 25) AS Title, CAST(ytd_sales AS char(2))
FROM titles
WHERE type = 'trad_cook'
El siguiente es el conjunto de resultados:
Title
------------------------- --
Onions, Leeks, and Garlic *
Fifty Years in Buckingham *
Sushi, Anyone? *
(3 row(s) affected)
Cuando se convierten tipos de datos que tienen un número diferente de posiciones decimales, el valor queda recortado hasta la cifra de mayor precisión. Por ejemplo, el resultado de SELECT CAST(10,6496 AS int) es 10.
Cuando se realiza una conversión entre tipos de datos donde el tipo de datos destino tiene menos posiciones decimales que el tipo de datos origen, el valor se redondea. Por ejemplo, el resultado de CAST(10,3496847 AS money) es $10,3497.
SQL Server devuelve un mensaje de error cuando los datos no numéricos char, nchar, varchar o nvarchar se convierten a int, float, numeric o decimal. SQL Server también devuelve un error cuando se convierte una cadena vacía (" ") a numeric o decimal.
Usar datos de cadenas Binary
Cuando se convierten datos binary o varbinary en datos de cadena de caracteres y se especifica un número impar de valores a continuación de la por, SQL Server agrega un 0 (cero) después de la por para tener un número par de valores.
Los datos de tipo binary se componen de los caracteres del 0 al 9 y de la A a la F (o de la a a la f), en grupos de dos caracteres cada uno. Las cadenas de tipo binary tienen que estar precedidas por 0x. Por ejemplo, para representar FF, escriba 0xFF. El valor máximo es un valor de tipo binary de 8000 bytes, cada uno de los cuales es FF. Los tipos de datos binary no sólo se utilizan para guardar datos hexadecimales, sino también para almacenar patrones de bits. Puede que las conversiones y cálculos de números hexadecimales almacenados como datos de tipo binary no sean confiables.
Cuando se especifica la longitud de un tipo de datos binary, cada dos caracteres cuentan como uno. La longitud 10 significa que hay 10 grupos de dos caracteres.
Las cadenas de tipo binary vacías, representadas como 0x, se pueden almacenar como datos de tipo binary.
Ejemplos
A. Utilizar CAST y CONVERT
Los dos ejemplos devuelven los títulos de aquellos libros que tienen un 3 en la primera cifra de las ventas anuales y convierten ytd_sales en char(20).
-- Use CAST.
USE pubs
GO
SELECT SUBSTRING(title, 1, 30) AS Title, ytd_sales
FROM titles
WHERE CAST(ytd_sales AS char(20)) LIKE '3%'
GO
-- Use CONVERT.
USE pubs
GO
SELECT SUBSTRING(title, 1, 30) AS Title, ytd_sales
FROM titles
WHERE CONVERT(char(20), ytd_sales) LIKE '3%'
GO
Éste es el conjunto de resultados (de las consultas):
Title ytd_sales
------------------------------ -----------
Cooking with Computers: Surrep 3876
Computer Phobic AND Non-Phobic 375
Emotional Security: A New Algo 3336
Onions, Leeks, and Garlic: Coo 375
(4 row(s) affected)
B. Utilizar CAST con operadores aritméticos
Este ejemplo calcula una única columna (Copies) dividiendo las ventas anuales totales (ytd_sales) por el precio individual del libro (price). El resultado se convierte en el tipo de datos int después de redondearlo al número entero más próximo.
USE pubs
GO
SELECT CAST(ROUND(ytd_sales/price, 0) AS int) AS 'Copies'
FROM titles
GO
El siguiente es el conjunto de resultados:
Copies
------
205
324
6262
205
102
7440
NULL
383
205
NULL
17
187
16
204
418
18
1263
273
(18 row(s) affected)
C. Utilizar CAST para concatenar
Este ejemplo concatena expresiones que no son de texto ni tipo binary mediante la función de conversión de tipos de datos CAST.
USE pubs
GO
SELECT 'The price is ' + CAST(price AS varchar(12))
FROM titles
WHERE price > 10.00
GO
El siguiente es el conjunto de resultados:
------------------
The price is 19.99
The price is 11.95
The price is 19.99
The price is 19.99
The price is 22.95
The price is 20.00
The price is 21.59
The price is 10.95
The price is 19.99
The price is 20.95
The price is 11.95
The price is 14.99
(12 row(s) affected)
D. Utilizar CAST para obtener texto más legible
Este ejemplo utiliza CAST en la lista seleccionada para convertir la columna title en una columna de tipo char(50), para que los resultados sean más legibles.
USE pubs
GO
SELECT CAST(title AS char(50)), ytd_sales
FROM titles
WHERE type = 'trad_cook'
GO
El siguiente es el conjunto de resultados:
ytd_sales
-------------------------------------------------- ---------
Onions, Leeks, and Garlic: Cooking Secrets of the 375
Fifty Years in Buckingham Palace Kitchens 15096
¿Sushi, Anyone? 4095
(3 row(s) affected)
E. Utilizar CAST con una cláusula LIKE
Este ejemplo convierte una columna de tipo int (la columna ytd_sales) en una columna de tipo char(20) para poder utilizarla en una cláusula LIKE.
USE pubs
GO
SELECT title, ytd_sales
FROM titles
WHERE CAST(ytd_sales AS char(20)) LIKE '15%'
AND type = 'trad_cook'
GO
El siguiente es el conjunto de resultados:
title ytd_sales
------------------------------------------------------------ -----------
Fifty Years in Buckingham Palace Kitchens 15096
(1 row(s) affected)
Véase también
Conversión de tipos de datos
SELECT
Funciones de sistema
©1988-2000 Microsoft Corporation. Reservados todos los derechos.
CAST y CONVERT
Convierten explícitamente una expresión de un tipo de datos en otro. CAST y CONVERT proporcionan funciones similares.
Sintaxis
Uso de CAST:
CAST ( expression AS data_type )
Uso de CONVERT:
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
Argumentos
Expression
¿Es cualquier expresión válida de Microsoft® SQL Server?. Para obtener más información, consulte Expresiones.
data_type
Es el tipo de datos de destino proporcionado por el sistema, incluido bigint y sql_variant. No se pueden utilizar tipos de datos definidos por el usuario. Para obtener más información acerca de los tipos de datos disponibles, consulte Tipos de datos.
length
Es un parámetro opcional de los tipos de datos nchar, nvarchar, char, varchar, binary o varbinary.
Style
Es el estilo del formato de fecha que se utiliza para convertir datos datetime o smalldatetime en datos de cadenas de caracteres (tipos de datos nchar, nvarchar, char, varchar, nchar o nvarchar), o el formato de cadena cuando se convierten datos float, real, money o smallmoney en datos de cadenas de caracteres (tipos de datos nchar, nvarchar, char, varchar, nchar o nvarchar).
SQL Server acepta el formato de fecha en estilo árabe, utilizando el algoritmo kuwaití.
En la siguiente tabla, las dos columnas de la izquierda representan los valores de style para la conversión de datetime o smalldatetime en cadenas de caracteres. Agregue 100 al valor de style para obtener el año con cuatro cifras, incluido el siglo (yyyy).
Sin el siglo
(Yy) Con el siglo
(Yyyy)
Estándar
Entrada/Salida**
- 0 o 100 (*) Valor predeterminado mon dd yyyy hh:miAM (o PM)
1 101 USA mm/dd/yy
2 102 ANSI yy.mm.dd
3 103 Británico/Francés dd/mm/yy
4 104 Alemán dd.mm.yy
5 105 Italiano dd-mm-yy
6 106 - dd mes aa
7 107 - Mes dd, aa
8 108 - hh:mm:ss
- 9 o 109 (*) Predeterminado + milisegundos mon dd yyyy hh:mi:ss:mmmAM (o PM)
10 110 USA mm-dd-yy
11 111 JAPÓN yy/mm/dd
12 112 ISO yymmdd
- 13 o 113 (*) Europeo predeterminado + milisegundos dd mon yyyy hh:mm:ss:mmm(24h)
14 114 - hh:mi:ss:mmm(24h)
- 20 o 120 (*) ODBC canónico yyyy-mm-dd hh:mi:ss(24h)
- 21 o 121 (*) ODBC canónico (con milisegundos) yyyy-mm-dd hh:mi:ss.mmm(24h)
- 126(***) ISO8601 yyyy-mm-dd Thh:mm:ss:mmm(sin espacios)
- 130* Kuwaití dd mon yyyy hh:mi:ss:mmmAM
- 131* Kuwaití dd/mm/yy hh:mi:ss:mmmAM
* Los valores predeterminados (style 0 o 100, 9 o 109, 13 o 113, 20 o 120, y 21 o 121) siempre devuelven el siglo (yyyy).
** Entrada cuando se convierte en datetime; salida cuando se convierte en cadenas de caracteres.
*** Diseñado para uso XML. Para la conversión de datos datetime o smalldatetime a character, el formato de salida es el que aparece descrito en la tabla. Para la conversión de datos float, money o smallmoney a character, la salida es equivalente a estilo 2. Para la conversión de datos real a character, la salda es equivalente a estilo 1.
Importante De forma predeterminada, SQL Server interpreta los años de dos cifras con el año 2049 como límite. Es decir, el año 49 se interpreta como 2049 y el año 50 se interpreta como 1950. Muchas aplicaciones de cliente, como las basadas en objetos de Automatización OLE, utilizan como límite el año 2030. SQL Server proporciona una opción de configuración (two digit year cutoff o reducción del año a dos dígitos) que cambia el año límite en SQL Server y permite el tratamiento coherente de las fechas. Sin embargo, el método más seguro es especificar los años con cuatro cifras.
Cuando se convierten cadenas de caracteres desde smalldatetime, los estilos que incluyen segundos o milisegundos muestran ceros en dichas posiciones. Puede recortar las partes de la fecha que no desee cuando convierta valores datetime o smalldatetime si utiliza la longitud apropiada en el tipo de datos char o varchar.
Esta tabla muestra los valores de style para la conversión de float o real en datos de cadenas de caracteres.
Valor Salida
0 (predeterminado) Seis cifras como máximo. Utiliza la notación científica cuando es apropiado.
1 Siempre ocho cifras. Utiliza siempre la notación científica.
2 Siempre 16 cifras. Utiliza siempre la notación científica.
En la siguiente tabla, la columna de la izquierda representa el valor de style para la conversión de money o smallmoney en datos de cadenas de caracteres.
Valor Salida
0 (predeterminado) Sin separadores de millar a la izquierda del separador decimal y dos cifras decimales; por ejemplo, 4235,98.
1 Separadores de millar a la izquierda del separador decimal y dos cifras decimales; por ejemplo, 3.510,92.
2 Sin separadores de millar a la izquierda del separador decimal y cuatro cifras decimales; por ejemplo, 4235,9819.
Tipos devueltos
Devuelve el mismo valor que si data type es 0.
Observaciones
Las conversiones implícitas son aquellas conversiones que ocurren sin especificar las funciones CAST o CONVERT. Las conversiones explícitas son aquellas conversiones que requieren que se especifique la función CAST (CONVERT). Este gráfico muestra todas las conversiones de tipos de datos explícitas e implícitas permitidas entre los tipos de datos del sistema de SQL Server, incluidos bigint y sql_variant.
Nota Como los datos Unicode siempre utilizan un número par de bytes, preste atención al convertir binary o varbinary en tipos de datos aceptados en Unicode, y viceversa. Por ejemplo, esta conversión no devuelve el valor hexadecimal 41, sino 4100: SELECT CAST(CAST(0x41 AS nvarchar) AS varbinary)
No se acepta la conversión automática para los tipos de datos text e image. Puede convertir explícitamente datos de tipo text en cadenas de caracteres y datos de tipo image en datos de tipo binary o varbinary, pero la longitud máxima es 8000. Si intenta una conversión incorrecta (por ejemplo, si convierte en int una expresión de cadena de caracteres que incluya letras), SQL Server genera un mensaje de error.
Si la salida de CAST o CONVERT es una cadena de caracteres y la entrada es otra cadena, la salida dispone de la misma intercalación y etiqueta de intercalación que la entrada. Si la entrada no es una cadena de caracteres, la salida tiene la intercalación predeterminada de la base de datos y una etiqueta de intercalación coaccionable-predeterminada. Para obtener más información, consulte Precedencia de intercalación.
Para asignar otra intercalación a la salida, aplique la cláusula COLLATE a la expresión de resultado de las funciones CAST o CONVERT. Por ejemplo:
SELECT CAST('abc' AS varchar(5)) COLLATE French_CS_AS
No existe una conversión implícita en la asignación del tipo de datos sql_variant, pero sí hay una conversión implícita a sql_variant.
Al convertir expresiones de caracteres o binarias (char, nchar, nvarchar, varchar, binary o varbinary) en una expresión de un tipo de datos diferente, los datos pueden quedar recortados, se pueden presentar parcialmente o se puede devolver un error porque el resultado es demasiado corto para ser presentado. Las conversiones en char, varchar, nchar, nvarchar, binary y varbinary se recortan, excepto en las conversiones que se muestran en esta tabla.
Del tipo de datos Al tipo de datos Resultado
int, smallint o tinyint char *
varchar *
nchar E
nvarchar E
money, smallmoney, numeric, decimal, float o real char E
varchar E
nchar E
nvarchar E
* Resultado demasiado corto para ser presentado.
E Error devuelto porque el resultado es demasiado corto para ser presentado.
Microsoft SQL Server garantiza que sólo las conversiones circulares, las conversiones que convierten un tipo de datos en otro y después vuelven a convertirlo en el tipo de datos original, devolverán los mismos valores en versiones diferentes. Este ejemplo muestra una conversión circular:
DECLARE @myval decimal (5, 2)
SET @myval = 193.57
SELECT CAST(CAST(@myval AS varbinary(20)) AS decimal(10,5))
-- Or, using CONVERT
SELECT CONVERT(decimal(10,5), CONVERT(varbinary(20), @myval))
No intente generar, por ejemplo, valores binary y convertirlos en un tipo de datos de la categoría de tipos de datos numéricos. SQL Server no garantiza que el resultado de una conversión de tipos de datos decimal o numeric a binary sea igual entre distintas versiones de SQL Server.
Este ejemplo muestra una expresión resultante demasiado corta para ser presentada.
USE pubs
SELECT SUBSTRING(title, 1, 25) AS Title, CAST(ytd_sales AS char(2))
FROM titles
WHERE type = 'trad_cook'
El siguiente es el conjunto de resultados:
Title
------------------------- --
Onions, Leeks, and Garlic *
Fifty Years in Buckingham *
Sushi, Anyone? *
(3 row(s) affected)
Cuando se convierten tipos de datos que tienen un número diferente de posiciones decimales, el valor queda recortado hasta la cifra de mayor precisión. Por ejemplo, el resultado de SELECT CAST(10,6496 AS int) es 10.
Cuando se realiza una conversión entre tipos de datos donde el tipo de datos destino tiene menos posiciones decimales que el tipo de datos origen, el valor se redondea. Por ejemplo, el resultado de CAST(10,3496847 AS money) es $10,3497.
SQL Server devuelve un mensaje de error cuando los datos no numéricos char, nchar, varchar o nvarchar se convierten a int, float, numeric o decimal. SQL Server también devuelve un error cuando se convierte una cadena vacía (" ") a numeric o decimal.
Usar datos de cadenas Binary
Cuando se convierten datos binary o varbinary en datos de cadena de caracteres y se especifica un número impar de valores a continuación de la por, SQL Server agrega un 0 (cero) después de la por para tener un número par de valores.
Los datos de tipo binary se componen de los caracteres del 0 al 9 y de la A a la F (o de la a a la f), en grupos de dos caracteres cada uno. Las cadenas de tipo binary tienen que estar precedidas por 0x. Por ejemplo, para representar FF, escriba 0xFF. El valor máximo es un valor de tipo binary de 8000 bytes, cada uno de los cuales es FF. Los tipos de datos binary no sólo se utilizan para guardar datos hexadecimales, sino también para almacenar patrones de bits. Puede que las conversiones y cálculos de números hexadecimales almacenados como datos de tipo binary no sean confiables.
Cuando se especifica la longitud de un tipo de datos binary, cada dos caracteres cuentan como uno. La longitud 10 significa que hay 10 grupos de dos caracteres.
Las cadenas de tipo binary vacías, representadas como 0x, se pueden almacenar como datos de tipo binary.
Ejemplos
A. Utilizar CAST y CONVERT
Los dos ejemplos devuelven los títulos de aquellos libros que tienen un 3 en la primera cifra de las ventas anuales y convierten ytd_sales en char(20).
-- Use CAST.
USE pubs
GO
SELECT SUBSTRING(title, 1, 30) AS Title, ytd_sales
FROM titles
WHERE CAST(ytd_sales AS char(20)) LIKE '3%'
GO
-- Use CONVERT.
USE pubs
GO
SELECT SUBSTRING(title, 1, 30) AS Title, ytd_sales
FROM titles
WHERE CONVERT(char(20), ytd_sales) LIKE '3%'
GO
Éste es el conjunto de resultados (de las consultas):
Title ytd_sales
------------------------------ -----------
Cooking with Computers: Surrep 3876
Computer Phobic AND Non-Phobic 375
Emotional Security: A New Algo 3336
Onions, Leeks, and Garlic: Coo 375
(4 row(s) affected)
B. Utilizar CAST con operadores aritméticos
Este ejemplo calcula una única columna (Copies) dividiendo las ventas anuales totales (ytd_sales) por el precio individual del libro (price). El resultado se convierte en el tipo de datos int después de redondearlo al número entero más próximo.
USE pubs
GO
SELECT CAST(ROUND(ytd_sales/price, 0) AS int) AS 'Copies'
FROM titles
GO
El siguiente es el conjunto de resultados:
Copies
------
205
324
6262
205
102
7440
NULL
383
205
NULL
17
187
16
204
418
18
1263
273
(18 row(s) affected)
C. Utilizar CAST para concatenar
Este ejemplo concatena expresiones que no son de texto ni tipo binary mediante la función de conversión de tipos de datos CAST.
USE pubs
GO
SELECT 'The price is ' + CAST(price AS varchar(12))
FROM titles
WHERE price > 10.00
GO
El siguiente es el conjunto de resultados:
------------------
The price is 19.99
The price is 11.95
The price is 19.99
The price is 19.99
The price is 22.95
The price is 20.00
The price is 21.59
The price is 10.95
The price is 19.99
The price is 20.95
The price is 11.95
The price is 14.99
(12 row(s) affected)
D. Utilizar CAST para obtener texto más legible
Este ejemplo utiliza CAST en la lista seleccionada para convertir la columna title en una columna de tipo char(50), para que los resultados sean más legibles.
USE pubs
GO
SELECT CAST(title AS char(50)), ytd_sales
FROM titles
WHERE type = 'trad_cook'
GO
El siguiente es el conjunto de resultados:
ytd_sales
-------------------------------------------------- ---------
Onions, Leeks, and Garlic: Cooking Secrets of the 375
Fifty Years in Buckingham Palace Kitchens 15096
¿Sushi, Anyone? 4095
(3 row(s) affected)
E. Utilizar CAST con una cláusula LIKE
Este ejemplo convierte una columna de tipo int (la columna ytd_sales) en una columna de tipo char(20) para poder utilizarla en una cláusula LIKE.
USE pubs
GO
SELECT title, ytd_sales
FROM titles
WHERE CAST(ytd_sales AS char(20)) LIKE '15%'
AND type = 'trad_cook'
GO
El siguiente es el conjunto de resultados:
title ytd_sales
------------------------------------------------------------ -----------
Fifty Years in Buckingham Palace Kitchens 15096
(1 row(s) affected)
Véase también
Conversión de tipos de datos
SELECT
Funciones de sistema
©1988-2000 Microsoft Corporation. Reservados todos los derechos.
