¿Qué Es La Inyección SQL Y Por Qué Es Peligrosa?

Los desarrolladores que trabajan con aplicaciones web ven muchas cosas que amenazan con dañar las cosas que construyen. Algunas de estas cosas incluyen ataques dirigidos a personas (por ejemplo, ingeniería social), algunos de estos ataques (ataques DoS o DDoS, secuencias de comandos entre sitios, falsificación de solicitudes entre sitios, autenticación rota, exposición de datos confidenciales, control de acceso roto, inseguridad). deserialización, etc.) partes de destino de las aplicaciones web. Sin embargo, algunos ataques se dirigen principalmente a su base de datos y los datos almacenados allí; uno de esos ataques es la inyección de SQL (SQLi para abreviar). En esta publicación de blog, veremos los impactos que podría tener un ataque de este tipo.

¿Qué es la inyección SQL y por qué es peligrosa?

La inyección SQL es un ataque frecuentemente dirigido a aplicaciones web. Con frecuencia, el propósito de un ataque de este tipo es extraer datos confidenciales de la base de datos y utilizarlos para el beneficio personal del atacante. Tal ataque es tan frecuente y peligroso precisamente porque muchos desarrolladores pasan por alto la importancia de la seguridad al crear soluciones públicas orientadas a la web. Cuando se pasan por alto las brechas de seguridad, las partes maliciosas a menudo las encuentran y las explotan. Estos actores nefastos explotan tales vulnerabilidades porque pueden beneficiarse de la venta de datos robados durante la violación.

Los impactos de tal ataque dependen de su aplicación web. Supongamos que su aplicación no almacena información confidencial, en cuyo caso, es probable que el ataque no tenga consecuencias de largo alcance. Sin embargo, si ese no es el caso, es posible que tenga un problema grave en sus manos: los datos confidenciales podrían ser robados y vendidos para obtener ganancias, causando problemas para su negocio y problemas innecesarios para sus clientes debido al estrés de restablecer contraseñas y cambiar información en otro lugar.

¿Cómo funciona la inyección SQL?

El concepto de inyección SQL es bastante simple: un ataque de este tipo funciona porque algunos desarrolladores ponen todo lo que el usuario escribe en un campo de entrada determinado en una consulta y lo pasan a una base de datos. Un fragmento básico de código vulnerable se vería así (también puede usar $_GET en lugar de $_POST, la premisa es la misma):

$Input = $_POST['input'];

SELECT * FROM demo_table WHERE column [= | < | > | <= | >= | LIKE ...] '$Input';

Como puede ver, en algunos de los casos, el código vulnerable es bastante simple (también puede volverse complejo, veremos diferentes escenarios más adelante): los atacantes explotan dicho código vulnerable con frecuencia usando el carácter de comilla (') para inducir errores. Una vez que induce errores, los atacantes saben que el código es vulnerable y pueden atacar nuestras aplicaciones.

Tipos de inyección SQL

Hay un par de categorías en las que se incluyen los ataques de inyección SQL:

  • Inyección SQL clásica : un tipo básico de inyección SQL cuando el atacante intenta ejecutar código SQL dentro de una base de datos para obtener acceso a una aplicación o cualquier otro sistema que haya implementado MySQL en su arquitectura de base de datos.
  • Inyección SQL basada en unión : un tipo de inyección SQL en el que un atacante usa la cláusula UNION en MySQL para combinar los resultados de las consultas que devuelven una respuesta útil para el atacante.
  • Inyección SQL basada en errores : un tipo de inyección SQL donde el atacante recopila datos principalmente a través de mensajes de error que se muestran (o no aparecen) en la aplicación que está siendo atacada. La inyección de SQL basada en errores tiene algunos tipos en sí misma.
  • Inyección SQL fuera de banda (OOB) : un tipo de inyección SQL en el que un atacante no puede usar la misma aplicación para atacar y recopilar resultados. Un tipo menos conocido de inyección SQL, pero un tipo no obstante.

Los atacantes usan cada uno de los tipos descritos anteriormente para lograr diferentes objetivos: la inyección SQL clásica es útil si el atacante tiene algún conocimiento implícito sobre el funcionamiento interno del sistema, la inyección SQL basada en unión puede ser útil si el atacante combina los resultados de un par de SELECTdeclaraciones en un solo conjunto de resultados, la inyección SQL basada en errores se usa cuando la aplicación es "silenciosa" (lo que significa que no devuelve ninguna respuesta, por lo que el atacante busca cambios en la funcionalidad al emitir ciertos tipos de consultas)

Protegiendo su aplicación de inyección SQL

En este punto, debe comprender bastante bien qué es la inyección de SQL y cuáles son sus tipos, pero ¿cómo protege sus aplicaciones de tal ataque? Afortunadamente, hay un par de formas conocidas de reducir el riesgo de que se explote una vulnerabilidad de este tipo ahora o en el futuro:

  • Mantenga todos los componentes de su aplicación actualizados e instale todos los parches de seguridad necesarios : mantener los componentes de la aplicación actualizados debería ser una primera línea de defensa efectiva contra cualquier ataque.
  • Valide la entrada : dado que el éxito de un ataque de este tipo depende en gran medida de la entrada que el atacante proporciona al sistema, la validación de entrada podría ser otra forma exitosa de prevenir ataques de inyección SQL ahora y en el futuro.
  • Use declaraciones parametrizadas : el uso de declaraciones parametrizadas es quizás la forma más efectiva de defenderse contra los ataques de inyección SQL. Cuando se utilizan sentencias parametrizadas, el servidor siempre interpreta la entrada del usuario como un valor y no la analiza. Por ejemplo:
/* Prepare MySQL statement */

if (!($statement = $mysqli->prepare(
	"SELECT customerID 
    FROM orders 
    WHERE item = ?"
    ))) {
    	echo "Failed: (" . $mysqli->errno . ") " . $mysqli->error;
}

/* 
Bind variables to statement as parameters using bind_param().
The type (first) parameter can take integers (i), doubles (d), 
strings(s), and blobs (b).
*/

$purchasedItem = 'ice cream';
if (!$statement->bind_param("s", $purchasedItem)) {    
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

/* Execute prepared MySQL statement */
if (!$statement->execute()) {
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

 

  • Use un firewall de aplicaciones web : el uso de un firewall de aplicaciones web (WAF) es otra línea de defensa efectiva porque los firewalls de aplicaciones web generalmente pueden identificar y bloquear múltiples tipos de ataques, incluida la inyección SQL, Cross-Site Scripting, Cross-Site Request Forgery , control de acceso roto, exposición de datos confidenciales, ataques DoS o DDoS, entre otros. Lo ideal es utilizar un firewall de aplicaciones web con declaraciones parametrizadas para obtener la máxima eficiencia y defensa contra la inyección SQL y otros tipos de ataques.
  • Use aplicaciones centradas en la seguridad proporcionadas por MySQL u otros proveedores : MySQL ofrece una forma de proteger sus aplicaciones contra la inyección de SQL a nivel empresarial mediante el uso de una herramienta MySQL Enterprise Firewall, que puede brindar protección en tiempo real contra amenazas específicas de la base de datos. Además, vale la pena analizar más a fondo varios otros proveedores (aparte de MySQL, algunos de ellos incluyen MariaDB, MinervaDB, MongoDB, Oracle, Variousnines y otros). Aún así, para esta publicación de blog, no vamos a entrar demasiado en detalles.
  • Evite otorgar privilegios administrativos cuando no sean necesarios : evitar otorgar privilegios innecesarios puede ser una fortaleza eficaz contra muchos tipos de ataques, incluida la escalada de privilegios y, por supuesto, la inyección SQL. Por ejemplo, si el usuario que usa su aplicación solo necesita ciertos derechos de acceso, considere otorgar solo los permisos necesarios para completar las tareas. Hacer cumplir la regla de privilegios mínimos en el nivel de la base de datos también es una excelente idea.

Tener estos puntos en mente debería ayudar a que su aplicación funcione bien.

Protegiendo su base de datos de la inyección SQL

El uso de declaraciones preparadas, el uso de complementos centrados en la seguridad proporcionados por MySQL, evitar otorgar privilegios administrativos innecesarios y tener en cuenta otras precauciones mencionadas anteriormente debería ponerlo a usted y a su base de datos en un buen camino. Sin embargo, si desea profundizar en MySQL y comprender por qué las consultas SQL funcionan de la manera en que lo hacen y por qué el uso de, por ejemplo, un firewall de aplicaciones web (WAF) podría protegerlo contra muchos tipos de ataques, incluida la inyección de SQL, considere esto:

  • Piense en cada consulta como una gran tarea que se compone de tareas más pequeñas.
  • Las tareas de la consulta se pueden observar ejecutandoSHOW PROFILE FOR QUERY [query id here];

Si se usa correctamente, en la mayoría de los casos, la salida le proporcionará lo que hizo la consulta y la duración de la tarea. También podrá observar un montón de cosas interesantes, incluida la obtención de respuestas a preguntas como:

  • ¿Cuánto tiempo tardó en iniciarse la consulta?
  • ¿Cuánto tiempo tomó la consulta para verificar los permisos?
  • ¿Cuánto tiempo tardó MySQL en abrir tablas?
  • ¿Cuánto tiempo tardó MySQL en inicializar los procesos?
  • ¿Cuánto tiempo tardó MySQL en optimizar, preparar y (o) ejecutar la consulta?
  • ¿Cuánto tiempo tardó MySQL en enviarle los datos para que los viera?
  • ¿Cuánto tiempo tardó MySQL en finalizar la consulta, cerrar tablas y liberar elementos?

Algunas de las respuestas a estas preguntas pueden ayudarlo a comprender por qué la inyección de SQL funciona de la manera en que lo hace. Por ejemplo, emita una SHOW PROFILE FOR QUERYconsulta nuevamente y verá lo siguiente:

Una parte del resultado de la consulta.SHOW PROFILE FOR QUERY

La fila marcada indica que inmediatamente después de comenzar a ejecutar la consulta, MySQL verifica los permisos. ¿Recuerdas lo que discutimos antes? Debe evitar otorgar privilegios innecesarios precisamente por este motivo: si la cuenta de MySQL a la que se dirige un atacante no tiene suficientes permisos, la consulta fallará. Dado que la funcionalidad de las SHOW PROFILE FOR QUERYconsultas no está dentro del alcance de esta publicación de blog, no vamos a entrar en demasiados detalles aquí, pero puede ver cómo y por qué es importante seguir los consejos anteriores.

La mayoría de los consejos descritos anteriormente también se aplican en el espacio de la base de datos:

  • Mantener actualizados todos los componentes de su aplicación incluye phpMyAdmin.
  • Validar la entrada incluye validar toda la entrada, no solo validar la entrada que es parte de algo.
  • Las declaraciones parametrizadas pueden (y deben) usarse en todas las ocasiones en las que se usan consultas SQL para evitar la filtración de datos de ciertas tablas.
  • El uso de un firewall de aplicaciones web y el uso de complementos enfocados en la seguridad pueden evitar que los atacantes obtengan acceso a su base de datos.
  • Evitar otorgar demasiados privilegios también podría salvar su base de datos de un desastre (consulte el ejemplo anterior)

Tenga en cuenta los consejos anteriores y debería estar bien encaminado para mitigar los problemas de inyección SQL que podrían afectar a su base de datos ahora o en el futuro.

Resumen

Como puede ver, la mayoría de los consejos que lo ayudan a proteger sus aplicaciones y bases de datos de la inyección de SQL son bastante generales y directos. Sin embargo, proteger sus bases de datos de la inyección de SQL tampoco es ciencia espacial: tenga en cuenta las pautas que se han descrito anteriormente, ¡y debería estar listo para comenzar! 

Fuente: https://arctype.com/blog/sql-injection/

#sql 

What is GEEK

Buddha Community

¿Qué Es La Inyección SQL Y Por Qué Es Peligrosa?
Cayla  Erdman

Cayla Erdman

1594369800

Introduction to Structured Query Language SQL pdf

SQL stands for Structured Query Language. SQL is a scripting language expected to store, control, and inquiry information put away in social databases. The main manifestation of SQL showed up in 1974, when a gathering in IBM built up the principal model of a social database. The primary business social database was discharged by Relational Software later turning out to be Oracle.

Models for SQL exist. In any case, the SQL that can be utilized on every last one of the major RDBMS today is in various flavors. This is because of two reasons:

1. The SQL order standard is genuinely intricate, and it isn’t handy to actualize the whole standard.

2. Every database seller needs an approach to separate its item from others.

Right now, contrasts are noted where fitting.

#programming books #beginning sql pdf #commands sql #download free sql full book pdf #introduction to sql pdf #introduction to sql ppt #introduction to sql #practical sql pdf #sql commands pdf with examples free download #sql commands #sql free bool download #sql guide #sql language #sql pdf #sql ppt #sql programming language #sql tutorial for beginners #sql tutorial pdf #sql #structured query language pdf #structured query language ppt #structured query language

¿Qué Es La Inyección SQL Y Por Qué Es Peligrosa?

Los desarrolladores que trabajan con aplicaciones web ven muchas cosas que amenazan con dañar las cosas que construyen. Algunas de estas cosas incluyen ataques dirigidos a personas (por ejemplo, ingeniería social), algunos de estos ataques (ataques DoS o DDoS, secuencias de comandos entre sitios, falsificación de solicitudes entre sitios, autenticación rota, exposición de datos confidenciales, control de acceso roto, inseguridad). deserialización, etc.) partes de destino de las aplicaciones web. Sin embargo, algunos ataques se dirigen principalmente a su base de datos y los datos almacenados allí; uno de esos ataques es la inyección de SQL (SQLi para abreviar). En esta publicación de blog, veremos los impactos que podría tener un ataque de este tipo.

¿Qué es la inyección SQL y por qué es peligrosa?

La inyección SQL es un ataque frecuentemente dirigido a aplicaciones web. Con frecuencia, el propósito de un ataque de este tipo es extraer datos confidenciales de la base de datos y utilizarlos para el beneficio personal del atacante. Tal ataque es tan frecuente y peligroso precisamente porque muchos desarrolladores pasan por alto la importancia de la seguridad al crear soluciones públicas orientadas a la web. Cuando se pasan por alto las brechas de seguridad, las partes maliciosas a menudo las encuentran y las explotan. Estos actores nefastos explotan tales vulnerabilidades porque pueden beneficiarse de la venta de datos robados durante la violación.

Los impactos de tal ataque dependen de su aplicación web. Supongamos que su aplicación no almacena información confidencial, en cuyo caso, es probable que el ataque no tenga consecuencias de largo alcance. Sin embargo, si ese no es el caso, es posible que tenga un problema grave en sus manos: los datos confidenciales podrían ser robados y vendidos para obtener ganancias, causando problemas para su negocio y problemas innecesarios para sus clientes debido al estrés de restablecer contraseñas y cambiar información en otro lugar.

¿Cómo funciona la inyección SQL?

El concepto de inyección SQL es bastante simple: un ataque de este tipo funciona porque algunos desarrolladores ponen todo lo que el usuario escribe en un campo de entrada determinado en una consulta y lo pasan a una base de datos. Un fragmento básico de código vulnerable se vería así (también puede usar $_GET en lugar de $_POST, la premisa es la misma):

$Input = $_POST['input'];

SELECT * FROM demo_table WHERE column [= | < | > | <= | >= | LIKE ...] '$Input';

Como puede ver, en algunos de los casos, el código vulnerable es bastante simple (también puede volverse complejo, veremos diferentes escenarios más adelante): los atacantes explotan dicho código vulnerable con frecuencia usando el carácter de comilla (') para inducir errores. Una vez que induce errores, los atacantes saben que el código es vulnerable y pueden atacar nuestras aplicaciones.

Tipos de inyección SQL

Hay un par de categorías en las que se incluyen los ataques de inyección SQL:

  • Inyección SQL clásica : un tipo básico de inyección SQL cuando el atacante intenta ejecutar código SQL dentro de una base de datos para obtener acceso a una aplicación o cualquier otro sistema que haya implementado MySQL en su arquitectura de base de datos.
  • Inyección SQL basada en unión : un tipo de inyección SQL en el que un atacante usa la cláusula UNION en MySQL para combinar los resultados de las consultas que devuelven una respuesta útil para el atacante.
  • Inyección SQL basada en errores : un tipo de inyección SQL donde el atacante recopila datos principalmente a través de mensajes de error que se muestran (o no aparecen) en la aplicación que está siendo atacada. La inyección de SQL basada en errores tiene algunos tipos en sí misma.
  • Inyección SQL fuera de banda (OOB) : un tipo de inyección SQL en el que un atacante no puede usar la misma aplicación para atacar y recopilar resultados. Un tipo menos conocido de inyección SQL, pero un tipo no obstante.

Los atacantes usan cada uno de los tipos descritos anteriormente para lograr diferentes objetivos: la inyección SQL clásica es útil si el atacante tiene algún conocimiento implícito sobre el funcionamiento interno del sistema, la inyección SQL basada en unión puede ser útil si el atacante combina los resultados de un par de SELECTdeclaraciones en un solo conjunto de resultados, la inyección SQL basada en errores se usa cuando la aplicación es "silenciosa" (lo que significa que no devuelve ninguna respuesta, por lo que el atacante busca cambios en la funcionalidad al emitir ciertos tipos de consultas)

Protegiendo su aplicación de inyección SQL

En este punto, debe comprender bastante bien qué es la inyección de SQL y cuáles son sus tipos, pero ¿cómo protege sus aplicaciones de tal ataque? Afortunadamente, hay un par de formas conocidas de reducir el riesgo de que se explote una vulnerabilidad de este tipo ahora o en el futuro:

  • Mantenga todos los componentes de su aplicación actualizados e instale todos los parches de seguridad necesarios : mantener los componentes de la aplicación actualizados debería ser una primera línea de defensa efectiva contra cualquier ataque.
  • Valide la entrada : dado que el éxito de un ataque de este tipo depende en gran medida de la entrada que el atacante proporciona al sistema, la validación de entrada podría ser otra forma exitosa de prevenir ataques de inyección SQL ahora y en el futuro.
  • Use declaraciones parametrizadas : el uso de declaraciones parametrizadas es quizás la forma más efectiva de defenderse contra los ataques de inyección SQL. Cuando se utilizan sentencias parametrizadas, el servidor siempre interpreta la entrada del usuario como un valor y no la analiza. Por ejemplo:
/* Prepare MySQL statement */

if (!($statement = $mysqli->prepare(
	"SELECT customerID 
    FROM orders 
    WHERE item = ?"
    ))) {
    	echo "Failed: (" . $mysqli->errno . ") " . $mysqli->error;
}

/* 
Bind variables to statement as parameters using bind_param().
The type (first) parameter can take integers (i), doubles (d), 
strings(s), and blobs (b).
*/

$purchasedItem = 'ice cream';
if (!$statement->bind_param("s", $purchasedItem)) {    
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

/* Execute prepared MySQL statement */
if (!$statement->execute()) {
    echo "Failed: (" . $statement->errno . ") " . $statement->error;
}

 

  • Use un firewall de aplicaciones web : el uso de un firewall de aplicaciones web (WAF) es otra línea de defensa efectiva porque los firewalls de aplicaciones web generalmente pueden identificar y bloquear múltiples tipos de ataques, incluida la inyección SQL, Cross-Site Scripting, Cross-Site Request Forgery , control de acceso roto, exposición de datos confidenciales, ataques DoS o DDoS, entre otros. Lo ideal es utilizar un firewall de aplicaciones web con declaraciones parametrizadas para obtener la máxima eficiencia y defensa contra la inyección SQL y otros tipos de ataques.
  • Use aplicaciones centradas en la seguridad proporcionadas por MySQL u otros proveedores : MySQL ofrece una forma de proteger sus aplicaciones contra la inyección de SQL a nivel empresarial mediante el uso de una herramienta MySQL Enterprise Firewall, que puede brindar protección en tiempo real contra amenazas específicas de la base de datos. Además, vale la pena analizar más a fondo varios otros proveedores (aparte de MySQL, algunos de ellos incluyen MariaDB, MinervaDB, MongoDB, Oracle, Variousnines y otros). Aún así, para esta publicación de blog, no vamos a entrar demasiado en detalles.
  • Evite otorgar privilegios administrativos cuando no sean necesarios : evitar otorgar privilegios innecesarios puede ser una fortaleza eficaz contra muchos tipos de ataques, incluida la escalada de privilegios y, por supuesto, la inyección SQL. Por ejemplo, si el usuario que usa su aplicación solo necesita ciertos derechos de acceso, considere otorgar solo los permisos necesarios para completar las tareas. Hacer cumplir la regla de privilegios mínimos en el nivel de la base de datos también es una excelente idea.

Tener estos puntos en mente debería ayudar a que su aplicación funcione bien.

Protegiendo su base de datos de la inyección SQL

El uso de declaraciones preparadas, el uso de complementos centrados en la seguridad proporcionados por MySQL, evitar otorgar privilegios administrativos innecesarios y tener en cuenta otras precauciones mencionadas anteriormente debería ponerlo a usted y a su base de datos en un buen camino. Sin embargo, si desea profundizar en MySQL y comprender por qué las consultas SQL funcionan de la manera en que lo hacen y por qué el uso de, por ejemplo, un firewall de aplicaciones web (WAF) podría protegerlo contra muchos tipos de ataques, incluida la inyección de SQL, considere esto:

  • Piense en cada consulta como una gran tarea que se compone de tareas más pequeñas.
  • Las tareas de la consulta se pueden observar ejecutandoSHOW PROFILE FOR QUERY [query id here];

Si se usa correctamente, en la mayoría de los casos, la salida le proporcionará lo que hizo la consulta y la duración de la tarea. También podrá observar un montón de cosas interesantes, incluida la obtención de respuestas a preguntas como:

  • ¿Cuánto tiempo tardó en iniciarse la consulta?
  • ¿Cuánto tiempo tomó la consulta para verificar los permisos?
  • ¿Cuánto tiempo tardó MySQL en abrir tablas?
  • ¿Cuánto tiempo tardó MySQL en inicializar los procesos?
  • ¿Cuánto tiempo tardó MySQL en optimizar, preparar y (o) ejecutar la consulta?
  • ¿Cuánto tiempo tardó MySQL en enviarle los datos para que los viera?
  • ¿Cuánto tiempo tardó MySQL en finalizar la consulta, cerrar tablas y liberar elementos?

Algunas de las respuestas a estas preguntas pueden ayudarlo a comprender por qué la inyección de SQL funciona de la manera en que lo hace. Por ejemplo, emita una SHOW PROFILE FOR QUERYconsulta nuevamente y verá lo siguiente:

Una parte del resultado de la consulta.SHOW PROFILE FOR QUERY

La fila marcada indica que inmediatamente después de comenzar a ejecutar la consulta, MySQL verifica los permisos. ¿Recuerdas lo que discutimos antes? Debe evitar otorgar privilegios innecesarios precisamente por este motivo: si la cuenta de MySQL a la que se dirige un atacante no tiene suficientes permisos, la consulta fallará. Dado que la funcionalidad de las SHOW PROFILE FOR QUERYconsultas no está dentro del alcance de esta publicación de blog, no vamos a entrar en demasiados detalles aquí, pero puede ver cómo y por qué es importante seguir los consejos anteriores.

La mayoría de los consejos descritos anteriormente también se aplican en el espacio de la base de datos:

  • Mantener actualizados todos los componentes de su aplicación incluye phpMyAdmin.
  • Validar la entrada incluye validar toda la entrada, no solo validar la entrada que es parte de algo.
  • Las declaraciones parametrizadas pueden (y deben) usarse en todas las ocasiones en las que se usan consultas SQL para evitar la filtración de datos de ciertas tablas.
  • El uso de un firewall de aplicaciones web y el uso de complementos enfocados en la seguridad pueden evitar que los atacantes obtengan acceso a su base de datos.
  • Evitar otorgar demasiados privilegios también podría salvar su base de datos de un desastre (consulte el ejemplo anterior)

Tenga en cuenta los consejos anteriores y debería estar bien encaminado para mitigar los problemas de inyección SQL que podrían afectar a su base de datos ahora o en el futuro.

Resumen

Como puede ver, la mayoría de los consejos que lo ayudan a proteger sus aplicaciones y bases de datos de la inyección de SQL son bastante generales y directos. Sin embargo, proteger sus bases de datos de la inyección de SQL tampoco es ciencia espacial: tenga en cuenta las pautas que se han descrito anteriormente, ¡y debería estar listo para comenzar! 

Fuente: https://arctype.com/blog/sql-injection/

#sql 

Cayla  Erdman

Cayla Erdman

1596441660

Welcome Back the T-SQL Debugger with SQL Complete – SQL Debugger

When you develop large chunks of T-SQL code with the help of the SQL Server Management Studio tool, it is essential to test the “Live” behavior of your code by making sure that each small piece of code works fine and being able to allocate any error message that may cause a failure within that code.

The easiest way to perform that would be to use the T-SQL debugger feature, which used to be built-in over the SQL Server Management Studio tool. But since the T-SQL debugger feature was removed completely from SQL Server Management Studio 18 and later editions, we need a replacement for that feature. This is because we cannot keep using the old versions of SSMS just to support the T-SQL Debugger feature without “enjoying” the new features and bug fixes that are released in the new SSMS versions.

If you plan to wait for SSMS to bring back the T-SQL Debugger feature, vote in the Put Debugger back into SSMS 18 to ask Microsoft to reintroduce it.

As for me, I searched for an alternative tool for a T-SQL Debugger SSMS built-in feature and found that Devart company rolled out a new T-SQL Debugger feature to version 6.4 of SQL – Complete tool. SQL Complete is an add-in for Visual Studio and SSMS that offers scripts autocompletion capabilities, which help develop and debug your SQL database project.

The SQL Debugger feature of SQL Complete allows you to check the execution of your scripts, procedures, functions, and triggers step by step by adding breakpoints to the lines where you plan to start, suspend, evaluate, step through, and then to continue the execution of your script.

You can download SQL Complete from the dbForge Download page and install it on your machine using a straight-forward installation wizard. The wizard will ask you to specify the installation path for the SQL Complete tool and the versions of SSMS and Visual Studio that you plan to install the SQL Complete on, as an add-in, from the versions that are installed on your machine, as shown below:

Once SQL Complete is fully installed on your machine, the dbForge SQL Complete installation wizard will notify you of whether the installation was completed successfully or the wizard faced any specific issue that you can troubleshoot and fix easily. If there are no issues, the wizard will provide you with an option to open the SSMS tool and start using the SQL Complete tool, as displayed below:

When you open SSMS, you will see a new “Debug” tools menu, under which you can navigate the SQL Debugger feature options. Besides, you will see a list of icons that will be used to control the debug mode of the T-SQL query at the leftmost side of the SSMS tool. If you cannot see the list, you can go to View -> Toolbars -> Debugger to make these icons visible.

During the debugging session, the SQL Debugger icons will be as follows:

The functionality of these icons within the SQL Debugger can be summarized as:

  • Adding Breakpoints to control the execution pause of the T-SQL script at a specific statement allows you to check the debugging information of the T-SQL statements such as the values for the parameters and the variables.
  • Step Into is “navigate” through the script statements one by one, allowing you to check how each statement behaves.
  • Step Over is “execute” a specific stored procedure if you are sure that it contains no error.
  • Step Out is “return” from the stored procedure, function, or trigger to the main debugging window.
  • Continue executing the script until reaching the next breakpoint.
  • Stop Debugging is “terminate” the debugging session.
  • Restart “stop and start” the current debugging session.

#sql server #sql #sql debugger #sql server #sql server stored procedure #ssms #t-sql queries

Cayla  Erdman

Cayla Erdman

1596448980

The Easy Guide on How to Use Subqueries in SQL Server

Let’s say the chief credit and collections officer asks you to list down the names of people, their unpaid balances per month, and the current running balance and wants you to import this data array into Excel. The purpose is to analyze the data and come up with an offer making payments lighter to mitigate the effects of the COVID19 pandemic.

Do you opt to use a query and a nested subquery or a join? What decision will you make?

SQL Subqueries – What Are They?

Before we do a deep dive into syntax, performance impact, and caveats, why not define a subquery first?

In the simplest terms, a subquery is a query within a query. While a query that embodies a subquery is the outer query, we refer to a subquery as the inner query or inner select. And parentheses enclose a subquery similar to the structure below:

SELECT 
 col1
,col2
,(subquery) as col3
FROM table1
[JOIN table2 ON table1.col1 = table2.col2]
WHERE col1 <operator> (subquery)

We are going to look upon the following points in this post:

  • SQL subquery syntax depending on different subquery types and operators.
  • When and in what sort of statements one can use a subquery.
  • Performance implications vs. JOINs.
  • Common caveats when using SQL subqueries.

As is customary, we provide examples and illustrations to enhance understanding. But bear in mind that the main focus of this post is on subqueries in SQL Server.

Now, let’s get started.

Make SQL Subqueries That Are Self-Contained or Correlated

For one thing, subqueries are categorized based on their dependency on the outer query.

Let me describe what a self-contained subquery is.

Self-contained subqueries (or sometimes referred to as non-correlated or simple subqueries) are independent of the tables in the outer query. Let me illustrate this:

-- Get sales orders of customers from Southwest United States 
-- (TerritoryID = 4)

USE [AdventureWorks]
GO
SELECT CustomerID, SalesOrderID
FROM Sales.SalesOrderHeader
WHERE CustomerID IN (SELECT [CustomerID]
                     FROM [AdventureWorks].[Sales].[Customer]
                     WHERE TerritoryID = 4)

As demonstrated in the above code, the subquery (enclosed in parentheses below) has no references to any column in the outer query. Additionally, you can highlight the subquery in SQL Server Management Studio and execute it without getting any runtime errors.

Which, in turn, leads to easier debugging of self-contained subqueries.

The next thing to consider is correlated subqueries. Compared to its self-contained counterpart, this one has at least one column being referenced from the outer query. To clarify, I will provide an example:

USE [AdventureWorks]
GO
SELECT DISTINCT a.LastName, a.FirstName, b.BusinessEntityID
FROM Person.Person AS p
JOIN HumanResources.Employee AS e ON p.BusinessEntityID = e.BusinessEntityID
WHERE 1262000.00 IN
    (SELECT [SalesQuota]
    FROM Sales.SalesPersonQuotaHistory spq
    WHERE p.BusinessEntityID = spq.BusinessEntityID)

Were you attentive enough to notice the reference to BusinessEntityID from the Person table? Well done!

Once a column from the outer query is referenced in the subquery, it becomes a correlated subquery. One more point to consider: if you highlight a subquery and execute it, an error will occur.

And yes, you are absolutely right: this makes correlated subqueries pretty harder to debug.

To make debugging possible, follow these steps:

  • isolate the subquery.
  • replace the reference to the outer query with a constant value.

Isolating the subquery for debugging will make it look like this:

SELECT [SalesQuota]
    FROM Sales.SalesPersonQuotaHistory spq
    WHERE spq.BusinessEntityID = <constant value>

Now, let’s dig a little deeper into the output of subqueries.

Make SQL Subqueries With 3 Possible Returned Values

Well, first, let’s think of what returned values can we expect from SQL subqueries.

In fact, there are 3 possible outcomes:

  • A single value
  • Multiple values
  • Whole tables

Single Value

Let’s start with single-valued output. This type of subquery can appear anywhere in the outer query where an expression is expected, like the WHERE clause.

-- Output a single value which is the maximum or last TransactionID
USE [AdventureWorks]
GO
SELECT TransactionID, ProductID, TransactionDate, Quantity
FROM Production.TransactionHistory
WHERE TransactionID = (SELECT MAX(t.TransactionID) 
                       FROM Production.TransactionHistory t)

When you use a MAX() function, you retrieve a single value. That’s exactly what happened to our subquery above. Using the equal (=) operator tells SQL Server that you expect a single value. Another thing: if the subquery returns multiple values using the equals (=) operator, you get an error, similar to the one below:

Msg 512, Level 16, State 1, Line 20
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.

Multiple Values

Next, we examine the multi-valued output. This kind of subquery returns a list of values with a single column. Additionally, operators like IN and NOT IN will expect one or more values.

-- Output multiple values which is a list of customers with lastnames that --- start with 'I'

USE [AdventureWorks]
GO
SELECT [SalesOrderID], [OrderDate], [ShipDate], [CustomerID]
FROM Sales.SalesOrderHeader
WHERE [CustomerID] IN (SELECT c.[CustomerID] FROM Sales.Customer c
INNER JOIN Person.Person p ON c.PersonID = p.BusinessEntityID
WHERE p.lastname LIKE N'I%' AND p.PersonType='SC')

Whole Table Values

And last but not least, why not delve into whole table outputs.

-- Output a table of values based on sales orders
USE [AdventureWorks]
GO
SELECT [ShipYear],
COUNT(DISTINCT [CustomerID]) AS CustomerCount
FROM (SELECT YEAR([ShipDate]) AS [ShipYear], [CustomerID] 
      FROM Sales.SalesOrderHeader) AS Shipments
GROUP BY [ShipYear]
ORDER BY [ShipYear]

Have you noticed the FROM clause?

Instead of using a table, it used a subquery. This is called a derived table or a table subquery.

And now, let me present you some ground rules when using this sort of query:

  • All columns in the subquery should have unique names. Much like a physical table, a derived table should have unique column names.
  • ORDER BY is not allowed unless TOP is also specified. That’s because the derived table represents a relational table where rows have no defined order.

In this case, a derived table has the benefits of a physical table. That’s why in our example, we can use COUNT() in one of the columns of the derived table.

That’s about all regarding subquery outputs. But before we get any further, you may have noticed that the logic behind the example for multiple values and others as well can also be done using a JOIN.

-- Output multiple values which is a list of customers with lastnames that start with 'I'
USE [AdventureWorks]
GO
SELECT o.[SalesOrderID], o.[OrderDate], o.[ShipDate], o.[CustomerID]
FROM Sales.SalesOrderHeader o
INNER JOIN Sales.Customer c on o.CustomerID = c.CustomerID
INNER JOIN Person.Person p ON c.PersonID = p.BusinessEntityID
WHERE p.LastName LIKE N'I%' AND p.PersonType = 'SC'

In fact, the output will be the same. But which one performs better?

Before we get into that, let me tell you that I have dedicated a section to this hot topic. We’ll examine it with complete execution plans and have a look at illustrations.

So, bear with me for a moment. Let’s discuss another way to place your subqueries.

#sql server #sql query #sql server #sql subqueries #t-sql statements #sql

Ruth  Nabimanya

Ruth Nabimanya

1621850444

List of Available Database for Current User In SQL Server

Introduction

When working in the SQL Server, we may have to check some other databases other than the current one which we are working. In that scenario we may not be sure that does we have access to those Databases?. In this article we discuss the list of databases that are available for the current logged user in SQL Server

Get the list of database
Conclusion

#sql server #available databases for current user #check database has access #list of available database #sql #sql query #sql server database #sql tips #sql tips and tricks #tips