You are on page 1of 24

Consultas de accin en SQL Las consultas de accin son aquellas que no devuelven ningn registro, son las encar

gadas de acciones como aadir y borrar y modificar registros. Tanto las sentencias de actualizacin como las de borrado desencadern (segn el motor de datos) las actua lizaciones en cascada, borrados en cascada, restricciones y valores por defecto definidos para los diferentes campos o tablas afectadas por la consulta. DELETE Crea una consulta de eliminacin que elimina los registros de una o ms de las tabla s listadas en la clusula FROM que satisfagan la clusula WHERE. Esta consulta elimi na los registros completos, no es posible eliminar el contenido de algn campo en concreto. Su sintaxis es: DELETE FROM Tabla WHERE criterio Una vez que se han eliminado los registros utilizando una consulta de borrado, n o puede deshacer la operacin. Si desea saber qu registros se eliminarn, primero exa mine los resultados de una consulta de seleccin que utilice el mismo criterio y d espus ejecute la consulta de borrado. Mantenga copias de seguridad de sus datos e n todo momento. Si elimina los registros equivocados podr recuperarlos desde las copias de seguridad. DELETE FROM Empleados WHERE Cargo = 'Vendedor' INSERT INTO Agrega un registro en una tabla. Se la conoce como una consulta de datos aadidos. Esta consulta puede ser de dos tipo: Insertar un nico registro Insertar en una t abla los registros contenidos en otra tabla. Para insertar un nico Registro: En este caso la sintaxis es la siguiente: INSERT INTO Tabla (campo1, campo2, ..., campoN) VALUES (valor1, valor2, ..., valorN) Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y as sucesivame nte. Para seleccionar registros e insertarlos en una tabla nueva En este caso la sintaxis es la siguiente: SELECT campo1, campo2, ..., campoN INTO nuevatabla FROM tablaorigen [WHERE criterios] Se pueden utilizar las consultas de creacin de tabla para archivar registros, hac er copias de seguridad de las tablas o hacer copias para exportar a otra base de datos o utilizar en informes que muestren los datos de un periodo de tiempo con creto. Por ejemplo, se podra crear un informe de Ventas mensuales por regin ejecut ando la misma consulta de creacin de tabla cada mes. Para insertar Registros de otra Tabla: En este caso la sintaxis es: INSERT INTO Tabla [IN base_externa] (campo1, campo2, , campoN)

SELECT TablaOrigen.campo1, TablaOrigen.campo2,,TablaOrigen.campoN FROM Tabla Origen ________________________________________________________________________________ _________________________ Subconsultas en SQL SubConsultas Una subconsulta es una instruccin SELECT anidada dentro de una instruccin SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta. Puede utilizar tres formas de sintaxis para crear una subconsulta: comparacin [ANY | ALL | SOME] (instruccin sql) expresin [NOT] IN (instruccin sql) [NOT] EXISTS (instruccin sql) En donde: comparacin Es una expresin y un operador de comparacin que compara la expresin con el resultad o de la subconsulta. expresin Es una expresin por la que se busca el conjunto resultante de la subconsulta. instruccin sql Es una instruccin SELECT, que sigue el mismo formato y reglas que cualquier otra instruccin SELECT. Debe ir entre parntesis. Se puede utilizar una subconsulta en lugar de una expresin en de una instruccin SELECT o en una clusula WHERE o HAVING. En tiliza una instruccin SELECT para proporcionar un conjunto de ecificados para evaluar en la expresin de la clusula WHERE o la lista de campos una subconsulta, se u uno o ms valores esp HAVING.

Se puede utilizar el predicado ANY o SOME, los cuales son sinnimos, para recupera r registros de la consulta principal, que satisfagan la comparacin con cualquier otro registro recuperado en la subconsulta. El ejemplo siguiente devuelve todos los productos cuyo precio unitario es mayor que el de cualquier producto vendido con un descuento igual o mayor al 25 por ciento.: SELECT * FROM Productos WHERE PrecioUnidad > ANY (SELECT PrecioUnidad FROM DetallePedido WHERE Descuento >= 0 .25); El predicado ALL se utiliza para recuperar nicamente aquellos registros de la con sulta principal que satisfacen la comparacin con todos los registros recuperados en la subconsulta. Si se cambia ANY por ALL en el ejemplo anterior, la consulta devolver nicamente aquellos productos cuyo precio unitario sea mayor que el de tod os los productos vendidos con un descuento igual o mayor al 25 por ciento. Esto es mucho ms restrictivo. El predicado IN se emplea para recuperar nicamente aquellos registros de la consu lta principal para los que algunos registros de la subconsulta contienen un valo r igual. El ejemplo siguiente devuelve todos los productos vendidos con un descu ento igual o mayor al 25 por ciento.:

SELECT * FROM Productos WHERE IDProducto IN (SELECT IDProducto FROM DetallePedido WHERE Descuento >= 0.25); Inversamente se puede utilizar NOT IN para recuperar nicamente aquellos registros de la consulta principal para los que no hay ningn registro de la subconsulta qu e contenga un valor igual. El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en compar aciones de verdad/falso para determinar si la subconsulta devuelve algn registro.

________________________________________________________________________________ _________________________ Recuperar una base de datos Alguna vez hemos perdido alguna base de datos ? y queremos recuperarla pero nos damos cuenta que no hemos hecho un backup, o mas fcil, el backup se ha hecho mal o esta corrupto. Bien, no es lo mas normal pero puede pasar, o simplemente quere mos instalar la misma base de datos en otro servidor SQL Server, por ejemplo par a desarrollo y no queremos hacer un transfer. Siempre que esos servidores SQL Se rver sean de la misma versin e instalados exactamente igual, es decir, mismo jueg o de caracteres y misma pagina de cdigos podemos utilizar el Stored Procedure de sistema (Base de datos MASTER) sp_attach_db para adjuntar la base de datos a nue stro SQL Server, de la siguiente forma : EXEC sp_attach_db @dbname = N'DATA', @filename1 = N'F:mssql7dataDATA_Data.mdf', @filename2 = N'F:mssql7dataDATA_log.ldf' Este sp lo podemos ejecutar desde el Query Analyzer seleccionando la base de dat os master. Donde : - @dbname es el nombre que le daremos a la base de datos - @filename1 es la ruta fsica de disco del fichero de la base de datos a adjuntar - @filename2 es la ruta fsica de disco del fichero de log de la base de datos Para mas informacin podeis mirar el sp_attach_db de los Books OnLine del SQL Serv er :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::. Cursores en SQL En algunos SGDB es posible la abertura de cursores de datos desde el propio ento rno de trabajo, para ello se utilizan, normalmente procedimientos almacenados. L a sintaxis para definir un cursor es la siguiente: DECLARE nombre-cursor FOR especificacion-consulta [ORDER BY] Por ejemplo:

DECLARE Mi_Cursor FOR SELECT num_emp, nombre, puesto, salario FROM empleados WHERE num_dept = 'informatica' Este comando es meramente declarativo, simplemente especifica las filas y column as que se van a recuperar. La consulta se ejecuta cuando se abre o se activa el cursor. La clusula [ORDER BY] es opcional y especifica una ordenacin para las fila s del cursor; si no se especifica, la ordenacin de las filas es definida el gesto r de SGBD. Para abrir o activar un cursor se utiliza el comando OPEN del SQL, la sintaxis e n la siguiente: OPEN nombre-cursor [USING lista-variables] Al abrir el cursor se evala la consulta que aparece en su definicin, utilizando lo s valores actuales de cualquier parmetro referenciado en la consulta, para produc ir una coleccin de filas. El puntero se posiciona delante de la primera fila de d atos (registro actual), esta sentencia no recupera ninguna fila. Una vez abierto el cursos se utiliza la clusula FETCH para recuperar las filas de l cursor, la sintaxis es la siguiente: FETCH nombre-cursor INTO lista-variables Lista - variables son las variables que van a contener los datos recuperados de la fila del cursor, en la definicin deben ir separadas por comas. En la lista de variables se deben definir tantas variables como columnas tenga la fila a recupe rar. Para cerrar un cursor se utiliza el comando CLOSE, este comando hace desaparecer el puntero sobre el registro actual. La sintaxis es: CLOSE nombre-cursor Por ltimo, y para eliminar el cursor se utiliza el comando DROP CURSOR. Su sintax is es la siguiente: DROP CURSOR nombre-cursor Ejemplo (sobre SQL-SERVER): 'Abrir un cursor y recorrelo DECLARE Employee_Cursor CURSOR FOR SELECT LastName, FirstName FROM Northwind.dbo.Employees WHERE LastName like 'B%' OPEN Employee_Cursor Cursores en SQL (2)

FETCH NEXT FROM Employee_Cursor WHILE @@FETCH_STATUS = 0 BEGIN FETCH NEXT FROM Employee_Cursor END CLOSE Employee_Cursor DEALLOCATE Employee_Cursor 'Abrir un cursor e imprimir su contenido SET NOCOUNT ON DECLARE @au_id varchar(11), @au_fname varchar(20), @au_lname varchar(40), @message varchar(80), @title varchar(80) PRINT "-------- Utah Authors report --------" DECLARE authors_cursor CURSOR FOR SELECT au_id, au_fname, au_lname FROM authors WHERE state = "UT" ORDER BY au_id OPEN authors_cursor FETCH NEXT FROM authors_cursor INTO @au_id, @au_fname, @au_lname WHILE @@FETCH_STATUS = 0 BEGIN PRINT " " SELECT @message = "----- Books by Author: " + @au_fname + " " + @au_lname PRINT @message

DECLARE titles_cursor CURSOR FOR SELECT t.title FROM titleauthor ta, titles t WHERE ta.title_id = t.title_id AND ta.au_id = au_id

OPEN titles_cursor

FETCH NEXT FROM titles_cursor INTO @title IF @@FETCH_STATUS <> 0 PRINT " <<No Books>>" WHILE @@FETCH_STATUS = 0 BEGIN SELECT @message = " " + @title PRINT @message FETCH NEXT FROM titles_cursor INTO @title END CLOSE titles_cursor DEALLOCATE titles_cursor

FETCH NEXT FROM authors_cursor INTO @au_id, @au_fname, @au_lname END CLOSE authors_cursor DEALLOCATE authors_cursor GO 'Recorrer un cursor USE pubs GO DECLARE authors_cursor CURSOR FOR SELECT au_lname FROM authors WHERE au_lname LIKE "B%" ORDER BY au_lname OPEN authors_cursor FETCH NEXT FROM authors_cursor WHILE @@FETCH_STATUS = 0 BEGIN FETCH NEXT FROM authors_cursor END CLOSE authors_cursor DEALLOCATE authors_cursor Cursores en SQL (3) 'Recorrer un cursor guardando los valores en variables USE pubs

GO DECLARE @au_lname varchar(40) DECLARE @au_fname varchar(20) DECLARE authors_cursor CURSOR FOR SELECTau_lname, au_fname FROM authors WHERE au_lname LIKE "B%" ORDER BY au_lname, au_fname OPEN authors_cursor FETCH NEXT FROM authors_cursor INTO @au_lname, @au_fname WHILE @@FETCH_STATUS = 0 BEGIN PRINT "Author: " + @au_fname + " " + @au_lname FETCH NEXT FROM authors_cursor INTO @au_lname, @au_fname END CLOSE authors_cursor DEALLOCATE authors_cursor :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Supresin y modificacin de tablas con SQL Supresin y modificacin de tablas con SQL Vemos sentencias en SQL para la supresion y modificacin tanto de tablas como de r estricciones. Supresin de tablas: DROP TABLE: suprime una tabla de la base de datos. Cada usuario puede borrar sus propias tablas, pero solo el administrador o algn usuario con el privilegio "DRO P ANY TABLE" puede borrar las tablas de otro usuario. Al suprimir una tabla tamb in se suprimen los ndices y los privilegios asociados a ella. Las vistas y los sinn imos creados a partir de esta tabla dejan de funcionar pero siguen existiendo en la base de datos por tanto deberamos eliminarlos. Ejemplo: DROP TABLE [USUARIO].NOMBRETABLA [CASCADE CONSTRAINTS]; TRUNCATE: permite suprimir todas las filas de una tabla y liberar el espacio ocu pado para otros usos sin que reaparezca la definicin de la tabla de la base de da tos. Una orden TRUNCATE no se puede anular, como tampoco activa disparadores DEL ETE. TRUNCATE TABLE [USUARIO.]NOMBRETABLA [{DROP | REUSE} STORAGE]; Modificacin de tablas: Se modifican las tablas de dos formas: Cambiando la definicin de una columna (MOD IFY) aadiendo una columna a una tabla existente (ADD): Formato: ALTER TABLE NOMBRETABLA

{[ADD (COLUMNA [,COLUMNA]?)] [MODIFY (COLUMNA [,COLUMNA]?)] [ADD CONSTRAINT RESTRICCION] [DROP CONSTRAINT RESTRICCION]}; ADD= Aade una columna o mas al final de una tabla. MODIFY= Modifica una o mas columnas existentes en la tabla. ADD CONSTRAINT= Aade una restriccin a la definicin de la tabla. DROP CONSTRAINT= Elimina una restriccin de la tabla. A la hora de aadir una columna a una tabla hay que tener en cuenta: * Si la columna no esta definida como NOT NULL se le puede aadir en cualquier mom ento. * Si la columna esta definida como NOT NULL se pueden seguir estos pasos: 1. Se aade una columna sin especificar NOT NULL. 2. Se da valor a la columna para cada una de las filas. 3. Se modifica la columna NOT NULL. Al modificar una columna de duna tabla se han de tener en cuenta: * Se puede aumentar la longitud de una columna en cualquier momento. * Es posible aumentar o disminuir el numero de posiciones decimales en una colum na de tipo NUMBER. * Si la columna es NULL en todas las filas de la tabla, se puede disminuir la lo ngitud y modificar el tipo de dato * La opcin MODIFY? NOT NULL solo ser posible cuando la tabla no contenga ninguna f ila con valor nulo en la columna que se modifica. Adicin de restricciones: Con la orden ALTER TABLE se aaden restricciones a una tabla. Formato: ALTER TABLE NOMBRETABLA ADD CONSTRAINT NOMBRECONSTRAINT Borrado de restricciones: La orden ALTER TABLE con la clusula DROP CONSTRAINT; con la que se borran las res tricciones con nombre y las asignadas por el sistema. Formato: ALTER TABLE NOMBRETABLA DROP CONSTRAINT NOMBRE_CONSTRAINT, NOMBRE_RESTRICCION: Autor: Agustin Jareo http://www.levanteweb.com/index.php?var=Supresion%20de%20tablas&var2=sql :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::: Sentencias de seleccin o consultas

Las consultas son el corazn del lenguaje SQL. La sentencia SELECT, que se utiliza para expresar consultas en SQL, es la ms potente y compleja de las sentencias SQ L. La sentencia SELECT recupera datos de una base de datos y los devuelve en forma de resultados de la consulta. Consta de seis clusulas: las dos primeras (SELECT y FROM) obligatorias y las otras cuatro opcionales. La forma de la sentencia SELECT soportada por Paradox es: SELECT [DISTINCT] {* | expresin_columna, ...} FROM nombretabla [alias_tabla] ... [WHERE expresin1 operador expresion2] [GROUP BY {expresin_columna, ...} ] [HAVING {condicin} ] [UNION [ALL] (SELECT ...)] [ORDER BY {expresin_orden [DESC | ASC], ... ] :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::: Funcin para el clculo de das laborables en SQL Funcin para el clculo de das laborables en SQL Funcin que nos permite calcular el nmero de das laborables entre una fecha y otra, con las validaciones pertinentes. /*Primeramente declaramos que vamos a crear una funcion, en este caso se llama D if Dias y recibe dos parmetros, la fecha inicial del perodo y la final*/ CREATE FUNCTION DifDias(@StartDate DATETIME,@EndDate DATETIME) RETURNS integer AS Begin //Con esta variable calculamos cuantos dias "normales" hay en el rango de fechas DECLARE @DaysBetween INT //Con esta variable acumulamos los dias totales DECLARE @BusinessDays INT //esta variable nos sirve de contador para saber cuando lleguemos al ultimo dia del rango DECLARE @Cnt INT /*esta variable es la que comparamos para saber si el dia que esta calculando es sbado o domingo*/ DECLARE @EvalDate DATETIME

/*Esta par de variables sirven para comparar las dos fechas, si son iguales, la funcion nos regresa un 0*/ DECLARE @ini VARCHAR(10) DECLARE @fin VARCHAR(10) //Inicializamos algunas variables SELECT @DaysBetween = 0 SELECT @BusinessDays = 0 SELECT @Cnt=0 //Calculamos cuantos dias normales hay en el rango de fechas SELECT @DaysBetween = DATEDIFF(DAY,@StartDate,@EndDate) + 1 /*Ordenamos el formato de las fechas para que no importando como se proporcionen se comparen igual*/ SELECT @ini = (SELECT CAST((CAST(datepart(dd,@StartDate)AS VARCHAR(2))+'/'+ CAST(datepart(mm,@StartDate)AS VARCHAR(2))+'/'+CAST(datepart(yy,@StartDate)AS VARCHAR(4))) as varchar(10))) SELECT @fin = (SELECT CAST((CAST(datepart(dd,@EndDate)AS VARCHAR(2))+'/'+ CAST(datepart(mm,@EndDate)AS VARCHAR(2))+'/'+ CAST(datepart(yy,@EndDate)AS VARCHAR(4)))as varchar(10))) //Se comparan las dos fechas IF @ini <>@fin BEGIN /*Si la diferencia de fechas es igual a dos, es porque solo ha transcurrido un d ia, asi que solo se valida que no vaya a marcar dias de mas*/ IF @DaysBetween = 2 BEGIN SELECT @BusinessDays = 1 END ELSE BEGIN WHILE @Cnt < @DaysBetween BEGIN /*Se Iguala la fecha a que vamos a calcular para saber si es sabado o domingo en la variable @EvalDate sumandole los dias que marque el contador, el cual no deb e ser mayor que el numero total de dias que hay en el rango de fechas*/ SELECT @EvalDate = @StartDate + @Cnt /*Utilizando la funcion datepart con el parametro dw que calcula que dia de la s emana corresponde una fecha determinada, determinados que no sea sabado (7) o do mingo (1)*/ IF ((datepart(dw,@EvalDate) <> 1) and (datepart(dw,@EvalDate) <> 7) ) BEGIN /*Si no es sabado o domingo, entonces se suma uno al total de dias que queremos desplegar*/

SELECT @BusinessDays = @BusinessDays + 1 END //Se suma un dia mas al contador SELECT @Cnt = @Cnt + 1 END END END ELSE BEGIN //Si fuese cierto que las fechas eran iguales se despliage cero SELECT @BusinessDays = 0 END //Al finalizar el ciclo, la funcion regresa el numero total de dias return (@BusinessDays) END Autor: Rosendo Lopez Robles :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::: Arquitectura de las bases de datos Los usuarios no tienen porque conocer como estn organizados y almacenados los dat os. Por este motivo una base de datos debe presentar los datos de forma que el usuar io pueda interpretarlos y modificarlos. Evidentemente esto no lo podemos aplicar a un informtico que necesite saber donde se encuentran fsicamente los datos para poder tratarlos. Podemos destacar tres niveles principales segn la visin y la funcin que realice el usuario sobre la base de datos: Nivel Interno: es el nivel ms cercano al almacenamiento fsico de los datos. Pe rmite escribirlos tal y como estn almacenados en el ordenador. En este nivel se d isean los archivos que contienen la informacin, la ubicacin de los mismos y su orga nizacin, es decir se crean los archivos de configuracin. Nivel conceptual: En este nivel se representan los datos que se van a utiliz ar sin tener en cuenta aspectos como lo que representamos en el nivel interno. Nivel externo: es el ms cercano al usuario. En este nivel se describen los da tos o parte de los datos que ms interesan a los usuarios. Estos tres niveles de visin de usuarios los proporcionan los sistemas gestores de base de datos (ya veremos ms adelante que significa esto). Una base de datos especifica tiene un nico nivel interno y un nico nivel conceptua l pero puede tener varios niveles externos. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::: Optimizar consultas SQL Distintas formas de optimizar las consultas realizadas en SQL. El lenguaje SQL es no procedimental, es decir, en las sentencias se indica que q ueremos conseguir y no como lo tiene que hacer el interprete para conseguirlo. E sto es pura teora, pues en la prctica a todos los gestores de SQL hay que especifi car sus propios truquitos para optimizar el rendimiento. Por tanto, muchas veces no basta con especificar una sentencia SQL correcta, sin o que adems, hay que indicarle como tiene que hacerlo si queremos que el tiempo d e respuesta sea el mnimo. En este apartado veremos como mejorar el tiempo de resp uesta de nuestro interprete ante unas determinadas situaciones: Diseo de las tablas Normaliza las tablas, al menos hasta la tercera forma normal, para asegurar que no hay duplicidad de datos y se aprovecha al mximo el almacenamiento en las t ablas. Si hay que desnormalizar alguna tabla piensa en la ocupacin y en el rendim iento antes de proceder. Los primeros campos de cada tabla deben ser aquellos campos requeridos y den tro de los requeridos primero se definen los de longitud fija y despus los de lon gitud variable. Ajusta al mximo el tamao de los campos para no desperdiciar espacio. Es muy habitual dejar un campo de texto para observaciones en las tablas. Si este campo se va a utilizar con poca frecuencia o si se ha definido con gran ta mao, por si acaso, es mejor crear una nueva tabla que contenga la clave primaria de la primera y el campo para observaciones. Gestin y eleccin de los ndices Los ndices son campos elegidos arbitrariamente por el constructor de la base de d atos que permiten la bsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo, esta ventaja se ve contrarrestada por el hecho de ocupar mucha ms memoria (el doble ms o menos) y de requerir para su insercin y actualizac in un tiempo de proceso superior. Evidentemente, no podemos indexar todos los campos de una tabla extensa ya que d oblamos el tamao de la base de datos. Igualmente, tampoco sirve de mucho el index ar todos los campos en una tabla pequea ya que las selecciones pueden efectuarse rpidamente de todos modos. Un caso en el que los ndices pueden resultar muy tiles es cuando realizamos petici ones simultneas sobre varias tablas. En este caso, el proceso de seleccin puede ac elerarse sensiblemente si indexamos los campos que sirven de nexo entre las dos tablas. Los ndices pueden resultar contraproducentes si los introducimos sobre campos tri viales a partir de los cuales no se realiza ningn tipo de peticin ya que, adems del problema de memoria ya mencionado, estamos ralentizando otras tareas de la base de datos como son la edicin, insercin y borrado. Es por ello que vale la pena pen srselo dos veces antes de indexar un campo que no sirve de criterio para bsquedas o que es usado con muy poca frecuencia por razones de mantenimiento. Campos a Seleccionar En la medida de lo posible hay que evitar que las sentencias SQL estn embebid

as dentro del cdigo de la aplicacin. Es mucho ms eficaz usar vistas o procedimiento s almacenados por que el gestor los guarda compilados. Si se trata de una senten cia embebida el gestor debe compilarla antes de ejecutarla. Seleccionar exclusivamente aquellos que se necesiten No utilizar nunca SELECT * por que el gestor debe leer primero la estructura de la tabla antes de ejecutar la sentencia Si utilizas varias tablas en la consulta especifica siempre a que tabla pert enece cada campo, le ahorras al gestor el tiempo de localizar a que tabla perten ece el campo. En lugar de SELECT Nombre, Factura FROM Clientes, Facturacion WHER E IdCliente = IdClienteFacturado, usa: SELECT Clientes.Nombre, Facturacion.Factu ra WHERE Clientes.IdCliente = Facturacion.IdClienteFacturado. Campos de Filtro Se procurar elegir en la clusula WHERE aquellos campos que formen parte de la clave del fichero por el cual interrogamos. Adems se especificarn en el mismo orde n en el que estn definidos en la clave. Interrogar siempre por campos que sean clave. Si deseamos interrogar por campos pertenecientes a ndices compuestos es mejor utilizar todos los campos de todos los ndices. Supongamos que tenemos un ndice fo rmado por el campo NOMBRE y el campo APELLIDO y otro ndice formado por el campo E DAD. La sentencia WHERE NOMBRE='Juan' AND APELLIDO Like '%' AND EDAD = 20 sera ms optima que WHERE NOMBRE = 'Juan' AND EDAD = 20 por que el gestor, en este segund o caso, no puede usar el primer ndice y ambas sentencias son equivalentes por que la condicin APELLIDO Like '%' devolvera todos los registros. Orden de las Tablas Cuando se utilizan varias tablas dentro de la consulta hay que tener cuidado con el orden empleado en la clusula FROM. Si deseamos saber cuantos alumnos se matri cularon en el ao 1996 y escribimos: FROM Alumnos, Matriculas WHERE Alumno.IdAlumn o = Matriculas.IdAlumno AND Matriculas.Ao = 1996 el gestor recorrer todos los alum nos para buscar sus matriculas y devolver las correspondientes. Si escribimos FR OM Matriculas, Alumnos WHERE Matriculas.Ao = 1996 AND Matriculas.IdAlumno = Alumn os.IdAlumnos, el gestor filtra las matrculas y despus selecciona los alumnos, de e sta forma tiene que recorrer menos registros. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::: Gestin de vistas en SQL Gestin de vistas en SQL Creacin y uso de vistas: No contienen informacin por si mismas, sino que estn basadas en las que contienen otras tablas y refleja los datos de estas. Si se suprime una tabla la vista asociada se invalida. Formato: CREATE [OR REPLACE] VIEW NOMBREVISTA [(COLUMNA [,COLUMNA])] AS CONSULTA; AS CONSULTA= Determina las columnas y las tablas que aparecern en la vista. [OR REPLACE]= Crea de nuevo la vista si ya exista. Para consultar la vista cread USER_VIEWS: SELECT VIEW_NAME FROM

Nota: al borrar las tablas, las vistas de esas tablas no se borran y quedan inut ilizadas. Borrado de vistas: Se hace con DROP VIEW. Formato: DROP VIEW NOMBREVISTA; Operaciones sobre vistas: Se pueden realizar las mismas operaciones que se hacen sobre las tablas. Restric ciones: Actualizacin Si una vista esta basada en una sola tabla, se pueden modificar las filas de la vista. La modificacin de la vista cambia la tabla sobre la que esta definida. Borrado de filas a travs de una vista= Para borrar filas de una tabla a travs de una vista, esta se debe crear: Con filas de una sola tabla. Sin utilizar la clusula GROUP BY ni DISTINCT. Sin usar funciones de grupo o referencias a pseudocolumnas. Actualizacin de filas a travs de una vista: Para actualizar filas en una tabla a travs de una vista, esta ha de estar definida segn las restricciones anteriores y , adems, ninguna de las columnas que se va a actualizar se habr definido como una expresin. Insercin de filas a travs de una vista: Para insertar filas en una tabla a travs de una vista se han de tener en cuenta todas las restricciones anteriores y, adems, todas las columnas obligatori as de la tabla asociada deben estar presentes en la vista. Manejo de expresiones y de funciones en vistas: Se pueden crear vistas usando funciones, expresiones en columnas y consu ltas avanzadas pero nicamente se parean consultar estas vistas. Tambin podemos modificar filas siempre y cuando la columna que se va a mo dificar no sea la columna expresad en forma de clculo o con funciones. Nota: No es posible insertar filas si las columnas de la vista contiene clculos o funciones. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::: Cmo manejar fechas en SQL Server Antes de empezar voy a tratar de explicar que son las Fechas para SqlServer. El Sql Server tiene bsicamente dos tipos de datos donde se pueden almacenar fecha s propiamente dichas, Datetime y SmallDateTime. En este cuadro veremos las difer encias entre estos dos tipos de Datos. DateTime Valores de Fecha y Hora que estn comprendidos entre 1/1/1763 y 31/12/9999. La hor a se expresa con una exactitud de hasta 1/300 de segundo SamallDateTime Valores de Fecha y Hora que estn comprendidos entre 1/1/1900 y 6/6/2079. El grado de precisin de la hora llega hasta el minuto

Bien ahora conocemos los tipos de datos de nuestro motor, pero la gran pregunta, Cmo Guarda internamente Sql Server las Fechas? Lo hace en formato MM/DD/YYY o lo h ar en DD/MM/YYYY?, bueno lamento decirles que nuestro motor siempre guarda las fe chas de una sola forma y no esta referida a ningn formato (Americano, Espaol, Japo ns ) como recin mencione Entonces? Bueno Sql Server guarda las fechas DateTime como enteros de 4 Bytes (Lo s primeros 4 Bytes almacenan la Fecha y los otros 4 Bytes la Hora), en SmallDate time como tienen menor precisin en lugar de ser dos grupos de 4 son dos grupos de 2. Bien ahora sabemos tambin no solo que tipos de datos tenemos para guardar nuestra s fechas y horas sino que tambin como las guarda el motor realmente. Con todo esto me estoy preguntando, Entonces porque cuando hago algn Select me tra e las fechas en un formato X (como por ejemplo el Americano)? Claro esto es as porque leer las fechas en grupos de Bytes no es muy elegante que digamos y nuestros usuarios no estaran muy contentos. Cmo manejar fechas en SQL Server (2) Bueno ahora entonces tenemos un dilema, ya que cuando quiera hacer una consulta por ejemplo entre fechas deba primero saber que tipo de Formato usar (Americano, Espaol, etc) ya que no es lo mismo 10-01-2004 (donde 10 es el da y 01 el mes) a 1 0-01-2004 (Donde 10 es el mes y 01 el da). Una de las tcnicas que veo que mas se usan es aplicar siempre un formato y con es o parece estar la cosa controlada, claro que no es para nada as ya que el formato depender de que idioma tenga definido nuestro usuario por lo cual esto nos puede traer muchas complicaciones. Entonces, Cmo hacer una consulta de fechas en un formato y no morir en el intento? , bueno ac hay una solucin muy interesante, y es el uso del Standard ANSI para las fechas, este Standard esta compuesto as: YYYYMMDD HH:mm:ss , si yo empiezo a util izar este formato para mis consultas no tendr problemas en ninguna de mis aplicac iones por mas que nuestro usuario este configurado en Ingles, Espaol o lo que fue re, ni tampoco si en un Windows tengo definido en su configuracin regional cualqu ier cosa. Ahora tenemos un poco de teora, pero la misma debe ir acompaada con alguna prctica no? Las cosas hay que demostrarlas para que nos convenzan, por lo menos es mi fo rma de hacer y pedir las cosas. Para nuestro ejemplo utilizaremos la Base de Datos Northwind que ya viene como e jemplo en nuestro Sql Server, de no tenerla favor de instalarla desde el instala dor correspondiente. /* Creamos un usuario donde su idioma predefinido es el Espaol */ sp_addlogin 'UserFechas','pepe','master','Espaol' /* vamos a darle acceso a nuestra Base de Datos Northwind */ use Northwind GO sp_grantdbaccess 'UserFechas' GO Ahora salimos de nuestro QA (Analizador de Consultas) y volveremos a entrar logi andonos con este nuevo usuario que creamos (Recuerden que la autentificacin de nu

estro motor en este caso debe ser Mixta y que el uso de cuentas de SqlServer no es aconsejable, sino que hay que tratar de utilizar la autentificacin Windows, pe ro para hacer el ejemplo mas fcil es que use Autentificacin Sql con un usuario Sql )

Cmo manejar fechas en SQL Server (3) Bien lo primero que haremos es verificar que el idioma este en espaol como lo hem os indicado anteriormente al usuario, para ello usaremos la siguiente instruccin. Select @@Language Este debera ser el resultado luego de ejecutar dicha consulta. --------------------------------------------------------Espaol (1 filas afectadas) Bien ahora usaremos la tabla Orders y haremos la consulta de fechas de dos forma s distintas, la primera usando los formatos como la mayora esta acostumbrado y la segunda utilizando el formato ANSI que seria el correcto. use northwind go -- Opcion que estamos acostumbrados a usar select count(*) from orders where orderdate >='01-08-1997' -- Opcion con Ansi select count(*) from orders where orderdate >='19970801' Bien ac veremos que en ambas consultas nos trae como retorno del Count 460, esto quiere decir que encontr 460 registros que su orderdate son mayor o igual a el 1 de Agosto de 1997. Bien ahora cambiaremos el lenguaje de nuestra sesin a ingles y haremos la misma c onsulta para ver que sucede: use northwind go /* Cambiamos el lenguaje para esta sesin a Ingles, esta opcin no cambia el lenguaje del Usuario sino que solo la sesin que al cerrarla volver a tomar la del usuario si Es que no especifico ningn SET LANGUAGE */ SET LANGUAGE us_english GO -- Opcin que estamos acostumbrados a usar select count(*) from orders where orderdate >='01-08-1997' -- Opcin con ANSI select count(*) from orders where orderdate >='19970801' Como vemos aqu la primer consulta paso de los 460 registros a los 670, porque suc

ede esto? Bueno como es ingles ahora la fecha que queremos consultar es realment e

Cmo manejar fechas en SQL Server (4) Mayor al 8 de enero de 1997, pero ejecuten la segunda consulta y vern que esta si gue retornando los 460 originales, pues bien esto es por todo lo que hemos dicho antes y porque es muy pero muy importante utilizar este tipo de formato (YYYYMM DD hh:mm:ss) Bien hemos aprendido a usar el formato ANSI para nuestras consultas pero eso no es todo, ahora trataremos de ver algunos ejemplos tpicos de bsquedas con fechas pa ra poder analizar bien estos casos. Una consulta muy recurrente es: Cmo busco los registros de una fecha en particular ya que me toma tambin la hora? Bueno esto es totalmente cierto, si ponemos por e jemplo = 20040101 esto traer los registros no del da 01 de enero del 2004 totalmente sino aquellos que sean de las 0 Horas, bueno para solucionar esto a mi me gusta usar esta consulta muy simple. Select * from orders Where orderdate >='19970805' and orderdate < dateadd(dd,1,' 19970805') Como vern primero es que sigo en la misma regla del ANSI y luego utilizo la funcin Dateadd para poder a la fecha sumarle un da, con esto logro que no me importe qu e hora tengan los registros que me traer todos los del da 05 de agosto de 1977. Bien ahora tenemos casi el 90% resuelto de los problemas ms habituales con fechas , pero de todos modos no deberamos dejar de ver las funciones que estn asociadas c on la manipulacin de Fechas Funcin Determinismo DATEADD Devuelve un valor datetime nuevo que se basa en la suma de un intervalo a la fec ha especificada. DATEDIFF Devuelve el nmero de lmites de fecha y hora que hay entre dos fechas especificadas . DATENAME Devuelve una cadena de caracteres que representa la parte de la fecha especifica da de la fecha especificada. DATEPART Devuelve un entero que representa la parte de la fecha especificada de la fecha indicada.. DAY Devuelve un entero que representa la parte del da de la fecha especificada. GETDATE Devuelve la fecha y hora actuales del sistema en el formato interno estndar de Mi crosoft SQL Server para los valores datetime.

Cmo manejar fechas en SQL Server (5) GETUTCDATE Devuelve el valor de datetime que representa la hora UTC actual (Universal Coord inated Time u hora del meridiano de Greenwich). La hora UTC actual se deriva de la hora local actual y la configuracin de zona horaria del sistema operativo del equipo en el que se ejecuta SQL Server. MONTH Devuelve un entero que representa el mes de una fecha especificada. YEAR Devuelve un entero que representa la parte de ao de la fecha especificada. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::: Tablas temporales en el SQL Server Introduccin En el mundo de las bases de datos es muy comn la utilizacin de tablas temporales. A pesar de que todo el mundo sabe que este tipo de estructuras ralentizan el fun cionamiento de nuestras consultas, los programadores no pueden evitar recurrir a ellas porque muchas veces facilitan la resolucin de problemas. Almacenar datos p ara usarlos posteriormente, guardar resultados parciales, analizar grandes canti dades de filas. Hay muchos casos en los que podemos necesitar estas tablas tempo rales, Pero hay que utilizarlas correctamente! Primer consejo: no usar tablas temporales El primer consejo que tenemos que seguir a la hora de trabajar con tablas tempor ales es bien sencillo: no usarlas. Y por qu no? Pues hay un montn de razones que ir emos viendo a lo largo de este texto, pero para empezar veamos en que se traduce el utilizar una tabla temporal en SQL Server: Las tablas temporales se crean en tempdb, y al crearlas se producen varios b loqueos sobre esta base de datos como por ejemplo en las tablas sysobjects y sys index. Los bloqueos sobre tempdb afectan a todo el servidor. Al crearlas es necesario que se realicen accesos de escritura al disco ( no siempre si las tablas son pequeas) Al introducir datos en las tablas temporales de nuevo se produce actividad e n el disco, y ya sabemos que el acceso a disco suele ser el "cuello de botella" de nuestro sistema Al leer datos de la tabla temporal hay que recurrir de nuevo al disco. Adems estos datos ledos de la tabla suelen combinarse con otros. Al borrar la tabla de nuevo hay que adquirir bloqueos sobre la base de datos tempdb y realizar operaciones en disco. Al usar tablas temporales dentro de un procedimiento almacenado perdemos la ventaja de tener compilado el plan de ejecucin de dicho procedimiento almacenado y se producirn recompilaciones ms a menudo. Lo mismo pasar cuando el SQL Server int enta reutilizar el plan de ejecucin de una consulta parametrizada. Si en la consu lta tenemos una tabla temporal difcilmente se reutilizar dicho plan de ejecucin. Vistos estos problemas creo que no hace falta repetir nuestro prime consejo.

Y qu podemos hacer entonces? En vez de tablas temporales podemos mejorar nuestro cdigo para que no sean necesa rias, podemos usar subconsultas (normalmente usar una subconsulta mejora drsticam ente el rendimiento respecto a usar tablas temporales), usar tablas permanentes, usar tablas derivadas. Hay que recordar siempre que cualquier alternativa es buena si evitamos usar tab las temporales (cursores excluidos por supuesto!) De todos modos si alguna vez tenemos que usarlas es mejor conocerlas bien, as que vamos a ello. Tipos de tablas temporales Las tablas temporales son de dos tipos en cuanto al alcance la tabla. Tenemos ta blas temporales locales y tablas temporales globales. #locales: Las tablas temporales locales tienen una # como primer carcter en su no mbre y slo se pueden utilizar en la conexin en la que el usuario las crea. Cuando la conexin termina la tabla temporal desaparece. ##globales Las tablas temporales globales comienzan con ## y son visibles por cu alquier usuario conectado al SQL Server. Y una cosa ms, ests tablas desaparecen cu ando ningn usuario est haciendo referencias a ellas, no cuado se desconecta el usu ario que la creo. Temp Realmente hay un tipo ms de tablas temporales. Si creamos una tabla dentro d e la base de datos temp es una tabla real en cuanto a que podemos utilizarla com o cualquier otra tabla en cualquier base de datos, y es temporal en cuanto a que desaparece en cuanto apagamos el servidor. Tablas temporales en el SQL Server (2) Funcionamiento de tablas temporales Crear una tabla temporal es igual que crear una tabla normal. Vemoslo con un ejem plo: CREATE TABLE #TablaTemporal (Campo1 int, Campo2 varchar(50)) Y se usan de manera habitual. INSERT INTO #TalbaTemporal VALUES (1,'Primer campo') INSERT INTO #TalbaTemporal VALUES (2,'Segundo campo') SELECT * FROM #TablaTemporal Como vemos no hay prcticamente limitaciones a la hora de trabajar con tablas temp orales (una limitacin es que no pueden tener restricciones FOREING KEY). Optimizar el uso de tablas temporales El uso que les podemos dar a este tipo de tablas es infinito, pero siempre tenie ndo en cuenta unas cuantas directivas que debemos seguir para que ralenticen nue stro trabajo lo menos posible. Por ejemplo no es mala costumbre crear las tablas temporales con comandos DDL co mo en el ejemplo anterior (CREATE TABLE) y luego rellenarlas comandos INSERT o c on INSERT INTO. Es cierto que eso mismo lo podemos lograr en un nico paso con SEL ECT INTO, pero esta opcin es peor porque los bloqueos que se adquieren sobre obje

tos del sistema duran ms tiempo. Como siempre es mejor pedir los campos que queremos y no poner el tpico SELCT * F ROM... De la misma manera es muy recomendable cualificar las filas que queremos y no tener filas que no vamos a utilizar en tablas temporales. Otra buena costumbre es borrar nosotros nuestras tablas. S que es cierto que al a cabar la conexin las tablas temporales locales desaparecen, pero si tenemos un co njunto de sentencias largo y creamos una tabla temporal al principio y no la vam os a utilizar en el resto del tiempo no tiene sentido tener esa tabla ah ocupando espacio y memoria. Si las tablas temporales son grandes una opcin para aumentar el rendimiento es cr ear un ndice que nos ayude a recuperar los datos de esa tabla (para tablas pequeas es un gasto intil porque nunca se usarn los ndices). Colocar la base de datos tempdb en un disco dedicado solo para esta funcin aument ar el rendimiento global del sistema si se hace un uso intensivo de tablas tempor ales. Y por ltimo pero no menos importante, no creis tablas temporales dentro de transac ciones ni dentro de triggers. creedme que la concurrencia de vuestra base de dat os sufrir mucho si lo hacis. Variables de tabla Con SQL Server 2000 podemos declarar variables de tipo table. Este tipo de varia bles tienen una serie de ventajas sobre las tablas temporales por lo que siempre que podamos escogeremos usar variables de tabla frente a tablas temporales. Usa r variables temporales es sencillo: DECLARE @VariableTabla TABLE (Campo1 int, Campo2 char(50)) INSERT INTO @VariableTabla VALUES (1,'Primer campo') INSERT INTO @VariableTabla VALUES (2,'Segundo campo') SELECT * FROM @VariableTabla Ventajas que encontraremos al usar variables de tipo tabla: Tienen un mbito bien definido. El procedimiento almacenado, la funcin o el bat ch en el que se declaran. Las variables de tipo tabla producen menos recompilaciones de los procedimie ntos almacenados en los que se encuentran que si utilizamos tablas temporales. Las variables de tabla no necesitan de bloqueos ni de tantos recursos como l as tablas temporales. Pero tambin tienen inconvenientes: No No No No podemos cambiar la definicin de la tabla una vez declarada podemos utilizar ndices que no sean agrupados se pueden utilizar en INSERT INTO ni en SELECT INTO podemos utilizar funciones en las restricciones

Si ponemos en una balanza las ventajas y los inconvenientes vemos que en general es mejor utilizar las variables de tipo tabla que las tablas temporales. Solo e n el caso de tener gran cantidad de datos en una tabla temporal y si la vamos a usar varias veces es preferible la opcin de tablas temporales porque en ellas pod emos definir ndices. Un ejemplo Todo esto est muy bien, pero como siempre lo mejor es ver un ejemplo en el que po

damos ver que merece la pena el esfuerzo de reprogramar nuestro cdigo para no usa r tablas temporales. Vamos a ver un ejemplo simple y alejado de la realidad pero que ilustre lo que q ueremos explicar en este texto. Vamos a utilizar la base de datos Northwind. En esta base de datos los pedidos se envan a travs de tres compaas de trasnportes: S peedy Express(1), United Package(2) y Federal Shipping(3). La compaa Federal Shipp ing nos oferta realizar todos los envos que hacemos a travs de United Package al p recio fijo de 10$. Decidimos que este ahorro merece la pena y vamos a cambiar en nuestra base de da tos todos los pedidos abiertos que tienen que ser enviados por United Package pa ra que sean enviados a travs de Federal Shipping. Para hacer esta actualizacin de los datos tenemos varias opciones. Vamos a compar ar tres formas de hacerlo.

Tablas temporales en el SQL Server (3) Metodo 1: Tablas temporales declare @st datetime SET @st =getdate() CREATE TABLE #Actualizar (OrderId int, ShipVia int, Freight money) INSERT INTO #Actualizar SELECT OrderID, ShipVia, Freight FROM Orders WHERE ShipVia=2 AND ShippedDate IS NULL UPDATE Orders SET ShipVia=3, Freight=10 WHERE OrderID IN (SELECT OrderID FROM #Actualizar)DROP TABLE #Actualizar PRINT 'Operacion completada en: ' + RTRIM(cast(datediff(ms,@st,getdate()) as cha r(10))) + ' milisegundos' Y obtenemos como resultado: (11 filas (11 filas Operacion Metodo 1: afectadas) afectadas) completada en: 140 milisegundos Variables tipo Tabla

DECLARE @st datetime SET @st =getdate() DECLARE @Actualizar TABLE(OrderId int, ShipVia int, Freight money) INSERT INTO @Actualizar SELECT OrderID, ShipVia, Freight FROM Orders WHERE ShipVia=2 AND ShippedDate IS NULL UPDATE Orders SET ShipVia=3, Freight=10 WHERE OrderID IN (SELECT OrderID FROM @Actualizar) PRINT 'Operacion completada en: ' + rtrim(cast(datediff(ms,@st,getdate()) AS cha r(10))) + ' milisegundos' Y en este caso el resultado es: (11 filas (11 filas Operacion Metodo 1: afectadas) afectadas) completada en: 73 milisegundos Sin Tablas temporales

DECLARE @st datetime

SET @st =getdate() UPDATE Orders SET ShipVia=3, Freight=10 WHERE OrderID IN (SELECT OrderID FROM Orders WHERE ShipVia=2 AND ShippedDate IS NULL) PRINT 'Operacion completada en: ' + rtrim(cast(datediff(ms,@st,getdate()) AS cha r(10))) + ' milisegundos' Y por ltimo obtenemos: (11 filas afectadas) Operacion completada en: 50 milisegundos Desde luego este ejemplo no es significativo, y en cada caso hay que estudiar la situacin y comparar los resultados obtenidos en un entorno de trabajo para saber cual es la mejor opcin, pero de todos modos espero que esto os sirva al menos pa ra conocer un poco mejor a las "tablas temporales". :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::: Las Interrelaciones Las interrelaciones son las relaciones que existen entre varias tablas del siste ma (Clientes y Pedidos, por ejemplo). Existen tres formas de interrelaciones dep endiendo de la cardinalidad con la que se combinan los elementos de ambas tablas . Interrelaciones uno a uno Una interrelacin es de uno a uno entre la tabla A y la tabla B cuando a cada elem ento de la clave de A se le asigna un nico elemento de la tabla B y para cada ele mento de la clave de la tabla B contiene un nico elemento en la tabla A. Un ejemp lo de interrelacin de este tipo es la formada por las tablas Datos Generales de C lientes y Datos Contables de Clientes. En esta relacin cada cliente tiene una nica direccin y una direccin en cada una de las tablas. Representamos la relacin como A 1: 1 B. Ante la presencia de este tipo de relacin nos podemos plantear el caso de unifica r todos los datos en nica tabla pues no es necesario mantener ambas tablas a la m isma vez. Este tipo de relacin se genera cuando aparecen tablas muy grandes, con gran canti dad de campos, disgregando la tabla principal en dos para evitar tener una tabla muy grande. Tambin surge cuando los diferentes grupos de usuario cumplimentan un a informacin diferente para un mismo registros; en este caso se crean tantas tabl as como registros, evitando as tener que acceder a informacin que el usuario del g rupo actual no necesita. Interrelaciones uno a varios Una interrelacin es de uno a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee un nico elemento relacionado en la tabla A. Estudiemos la relacin entre la tabla de clientes y la tabla de pedidos. Un client e puede realizar varios pedidos pero un pedido pertenece a un nico cliente, por t anto se trata de una relacin uno a varios y la representamos A 1: n B. Estas relaciones suelen surgir de aplicar la 1NF a una tabla. Interrelaciones varios a varios

Una interrelacin es de varios a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee varios elementos relacionados en la tabla A. Un caso muy caracterstico de esta interrelacin es la que surge entre las tablas de Puestos de Trabajo y Empleados de una empresa. Un Empleado puede desempear reali zar varias funciones dentro de una empresa (desempear varios puestos de trabajo), y un puesto de trabajo puede estar ocupado por varios empleados a la misma vez. Esta interrelacin la representamos como A n: n B.

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::: Bases de Datos Externas en SQL Para el acceso a bases de datos externas se utiliza la clusula IN. Se puede acced er a base de datos dBase, Paradox o Btrieve. Esta clusula slo permite la conexin de una base de datos externa a la vez. Una base de datos externa es una base de da tos que no sea la activa. Aunque para mejorar los rendimientos es mejor adjuntar las a la base de datos actual y trabajar con ellas. Para especificar una base de datos que no pertenece a Access Basic, se agrega un punto y coma (;) al nombre y se encierra entre comillas simples. Tambin puede ut ilizar la palabra reservada DATABASE para especificar la base de datos externa. Por ejemplo, las lneas siguientes especifican la misma tabla: FROM Tabla IN '[dBASE IV; DATABASE=C:DBASEDATOSVENTAS;]'; FROM Tabla IN 'C:DBASEDATOSVENTAS' 'dBASE IV;' Acceso a una base de datos externa de Microsoft Access: SELECT IDCliente FROM Clientes IN MISDATOS.MDB WHERE IDCliente Like 'A*'; En donde MISDATOS.MDB es el nombre de una base de datos de Microsoft Access que contiene la tabla Clientes. Acceso a una base de datos externa de dBASE III o IV: SELECT IDCliente FROM Clientes IN 'C:DBASEDATOSVENTAS' 'dBASE IV'; WHERE IDCliente Like 'A*'; Para recuperar datos de una tabla de dBASE III+ hay que utilizar 'dBASE III+;' e n lugar de 'dBASE IV;'. Acceso a una base de datos de Paradox 3.x o 4.x: SELECT IDCliente FROM Clientes IN 'C:PARADOXDATOSVENTAS' 'Paradox 4.x;' WHERE IDCliente Like 'A*'; Para recuperar datos de una tabla de Paradox versin 3.x, hay que sustituir 'Parad ox 4.x;' por 'Paradox 3.x;'. Acceso a una base de datos de Btrieve: SELECT IDCliente FROM Clientes IN 'C:BTRIEVEDATOSVENTASFILE.DDF' 'Btrieve;' WHERE IDCliente Like 'A*';

C:BTRIEVEDATOSVENTASFILE.DDF es la ruta de acceso y nombre de archivo del archiv o de definicin de datos de Btrieve.

You might also like