Iara  Simões

Iara Simões

1656069852

O Que é Injeção De SQL E Por Que é Perigoso?

Os desenvolvedores que lidam com aplicativos da Web veem muitas coisas ameaçando prejudicar as coisas que eles constroem. Algumas dessas coisas incluem ataques direcionados a pessoas (por exemplo, engenharia social), alguns desses ataques (ataques DoS ou DDoS, Cross-Site Scripting, Cross-Site Request Forgery, Broken Authentication, Sensitive Data Exposure, Broken Access Control, Insecure Desserialização, etc.) segmentam partes de aplicativos da web. No entanto, alguns ataques visam principalmente seu banco de dados e os dados armazenados nele - um desses ataques é a injeção de SQL (SQLi para abreviar). Nesta postagem do blog, veremos os impactos que esse ataque pode ter.

O que é injeção de SQL e por que é perigoso?

A injeção de SQL é um ataque frequentemente direcionado a aplicativos da web. O objetivo desse ataque frequentemente é exfiltrar dados confidenciais do banco de dados e usá-los para ganho pessoal do invasor. Tal ataque é tão prevalente e perigoso precisamente porque muitos desenvolvedores ignoram a importância da segurança ao criar soluções públicas voltadas para a web. Quando as falhas de segurança são ignoradas, as partes mal-intencionadas geralmente as encontram e exploram. Esses atores nefastos exploram essas vulnerabilidades porque podem lucrar com a venda de dados roubados durante a violação.

Os impactos de tal ataque dependem do seu aplicativo da web. Suponha que seu aplicativo não armazene informações confidenciais e, nesse caso, o ataque provavelmente não teria consequências de longo alcance. No entanto, se esse não for o caso, você pode ter um problema sério em suas mãos – dados confidenciais podem ser roubados e vendidos para obter lucro, causando problemas para seus negócios e problemas desnecessários para seus clientes devido ao estresse de redefinir senhas e alterar informações em outros lugares.

Como funciona a injeção de SQL?

O conceito de injeção de SQL é bem simples: esse ataque funciona porque alguns desenvolvedores colocam tudo o que o usuário escreve em um determinado campo de entrada em uma consulta e o repassam para um banco de dados. Um snippet básico de código vulnerável ficaria assim (você também pode usar $_GET em vez de $_POST, a premissa é a mesma):

$Input = $_POST['input'];

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

Como você pode ver, em alguns dos casos, o código vulnerável é bastante simples (também pode ficar complexo, entraremos em diferentes cenários mais tarde) – esse código vulnerável é então explorado por invasores frequentemente usando o caractere de aspas (') para induzir erros. Uma vez que induz a erros, os invasores sabem que o código é vulnerável e podem atacar nossos aplicativos.

Tipos de injeção de SQL

Existem algumas categorias em que os ataques de injeção de SQL se enquadram:

  • Injeção SQL clássica – um tipo básico de injeção SQL quando o invasor visa executar código SQL dentro de um banco de dados para obter acesso a um aplicativo ou qualquer outro sistema que tenha implementado o MySQL em sua arquitetura de banco de dados.
  • Injeção SQL baseada em união – um tipo de injeção SQL em que um invasor usa a cláusula UNION no MySQL para combinar os resultados de consultas que retornam uma resposta útil para o invasor.
  • Injeção de SQL baseada em erro – um tipo de injeção de SQL em que o invasor coleta dados principalmente por meio de mensagens de erro exibidas (ou ausentes) no aplicativo que está sendo atacado. A injeção de SQL baseada em erros tem alguns tipos por si só.
  • Injeção de SQL fora de banda (OOB) – um tipo de injeção de SQL em que um invasor não pode usar o mesmo aplicativo para atacar e coletar resultados. Um tipo menos conhecido de injeção de SQL, mas ainda assim um tipo.

Os invasores usam cada um dos tipos descritos acima para atingir objetivos diferentes – a injeção SQL clássica é útil se o invasor tiver algum conhecimento implícito sobre o funcionamento interno do sistema, a injeção SQL baseada em união pode ser útil se o invasor combinar os resultados de alguns de SELECTinstruções em um único conjunto de resultados, a injeção de SQL baseada em erros é usada quando o aplicativo é "silencioso" (o que significa que ele não retorna nenhuma resposta, portanto, o invasor procura alterações de funcionalidade ao emitir determinados tipos de consultas)

Protegendo seu aplicativo contra injeção de SQL

Neste ponto, você deve ter uma boa compreensão do que é injeção de SQL e quais são seus tipos, mas como proteger seus aplicativos de tal ataque? Felizmente, existem algumas maneiras bem conhecidas de diminuir o risco de tal vulnerabilidade ser explorada agora ou no futuro:

  • Mantenha todos os componentes do aplicativo atualizados e instale todos os patches de segurança necessários – manter os componentes do aplicativo atualizados deve ser uma primeira linha de defesa eficaz contra qualquer ataque.
  • Validar entrada – como o sucesso de tal ataque depende muito da entrada que o invasor fornece ao sistema, a validação de entrada pode ser outra maneira bem-sucedida de evitar ataques de injeção de SQL agora e no futuro.
  • Use instruções parametrizadas – o uso de instruções parametrizadas talvez seja a maneira mais eficaz de se defender contra ataques de injeção de SQL. Quando instruções parametrizadas estão em uso, o servidor sempre interpreta a entrada do usuário como um valor e não a analisa. Por exemplo:
/* 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 um firewall de aplicativo da Web – usar um firewall de aplicativo da Web (WAF) é outra linha de defesa eficaz porque os firewalls de aplicativo da Web geralmente são capazes de identificar e bloquear vários tipos de ataques, incluindo injeção de SQL, script entre sites, falsificação de solicitação entre sites , controle de acesso quebrado, exposição de dados confidenciais, ataques DoS ou DDoS, entre outros. Idealmente, um firewall de aplicativo da Web deve ser usado com instruções parametrizadas para máxima eficiência e defesa contra injeção de SQL e outros tipos de ataques.
  • Use aplicativos focados em segurança fornecidos pelo MySQL ou outros fornecedores – o MySQL oferece uma maneira de proteger seus aplicativos contra injeção de SQL no nível corporativo usando uma ferramenta MySQL Enterprise Firewall, que pode fornecer proteção em tempo real contra ameaças específicas de banco de dados. Além disso, vale a pena discutir mais sobre vários outros fornecedores (além do MySQL, alguns deles incluem MariaDB, MinervaDB, MongoDB, Oracle, Variousnines e outros). Ainda assim, para esta postagem no blog, não vamos entrar em muitos detalhes.
  • Evite conceder privilégios administrativos quando não forem necessários – evitar conceder privilégios desnecessários pode ser uma fortaleza eficaz contra muitos tipos de ataques, incluindo escalação de privilégios e, claro, injeção de SQL. Por exemplo, se o usuário que usa seu aplicativo precisar apenas de determinados direitos de acesso, considere conceder apenas as permissões necessárias para concluir as tarefas. Impor a regra de privilégio mínimo no nível do banco de dados também é uma excelente ideia.

Manter esses pontos em mente deve ajudar a manter seu aplicativo funcionando bem.

Protegendo seu banco de dados contra injeção de SQL

Usar declarações preparadas, usar plugins focados em segurança fornecidos pelo MySQL, evitar conceder privilégios administrativos desnecessários e levar em consideração outras precauções mencionadas acima devem colocar você e seu banco de dados em um bom caminho. No entanto, se você quiser se aprofundar no MySQL e entender por que as consultas SQL funcionam da maneira que funcionam e por que usar um, por exemplo, um firewall de aplicativo da Web (WAF) pode protegê-lo contra vários tipos de ataques, incluindo injeção de SQL, considere o seguinte:

  • Pense em cada consulta como uma grande tarefa composta de tarefas menores.
  • As tarefas da consulta podem ser observadas executandoSHOW PROFILE FOR QUERY [query id here];

Se usado corretamente, na maioria dos casos, a saída fornecerá o que a consulta fez e a duração da tarefa. Você também poderá observar um monte de coisas interessantes, incluindo obter respostas para perguntas como:

  • Quanto tempo levou para iniciar a consulta?
  • Quanto tempo a consulta levou para verificar as permissões?
  • Quanto tempo levou para o MySQL abrir tabelas?
  • Quanto tempo levou para o MySQL inicializar os processos?
  • Quanto tempo levou para o MySQL otimizar, preparar e (ou) executar a consulta?
  • Quanto tempo levou para o MySQL enviar os dados de volta para você ser visualizado?
  • Quanto tempo levou para o MySQL encerrar a consulta, fechar tabelas, liberar itens?

Algumas das respostas a essas perguntas podem ajudá-lo a entender por que a injeção de SQL funciona da maneira que funciona. Por exemplo, emita uma SHOW PROFILE FOR QUERYconsulta novamente e você verá o seguinte:

Uma parte da saída da consultaSHOW PROFILE FOR QUERY

A linha marcada indica que logo após iniciar a execução da consulta, o MySQL verifica as permissões. Lembra do que discutimos anteriormente? Você deve evitar conceder privilégios desnecessários precisamente por esse motivo – se a conta MySQL que um invasor está mirando não tiver permissões suficientes, a consulta falhará. Como a funcionalidade das SHOW PROFILE FOR QUERYconsultas não está no escopo desta postagem do blog, não entraremos em muitos detalhes aqui, mas você pode ver como e por que seguir os conselhos acima é importante.

A maioria dos conselhos descritos acima também é aplicável no espaço do banco de dados:

  • Manter todos os componentes do seu aplicativo atualizados inclui o phpMyAdmin.
  • Validar entrada inclui validar todas as entradas, não apenas validar entradas que fazem parte de algo.
  • As instruções parametrizadas podem (e devem) ser usadas em todas as ocasiões em que as consultas SQL são usadas para evitar a exfiltração de dados de determinadas tabelas.
  • Usar um firewall de aplicativo da Web e usar plug-ins com foco em segurança pode impedir que invasores obtenham acesso ao seu banco de dados.
  • Evitar conceder muitos privilégios também pode salvar seu banco de dados do desastre (consulte o exemplo acima)

Leve em consideração os conselhos acima e você deve estar no caminho certo para mitigar os problemas de injeção de SQL que podem atingir seu banco de dados agora ou no futuro.

Resumo

Como você pode dizer, a maioria dos conselhos que ajudam a proteger seus aplicativos e bancos de dados da injeção de SQL é bastante geral e direto. No entanto, proteger seus bancos de dados da injeção de SQL também não é ciência de foguetes – mantenha as diretrizes descritas acima em mente e você deve estar pronto! 

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

#sql 

What is GEEK

Buddha Community

O Que é Injeção De SQL E Por Que é Perigoso?
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

Iara  Simões

Iara Simões

1656069852

O Que é Injeção De SQL E Por Que é Perigoso?

Os desenvolvedores que lidam com aplicativos da Web veem muitas coisas ameaçando prejudicar as coisas que eles constroem. Algumas dessas coisas incluem ataques direcionados a pessoas (por exemplo, engenharia social), alguns desses ataques (ataques DoS ou DDoS, Cross-Site Scripting, Cross-Site Request Forgery, Broken Authentication, Sensitive Data Exposure, Broken Access Control, Insecure Desserialização, etc.) segmentam partes de aplicativos da web. No entanto, alguns ataques visam principalmente seu banco de dados e os dados armazenados nele - um desses ataques é a injeção de SQL (SQLi para abreviar). Nesta postagem do blog, veremos os impactos que esse ataque pode ter.

O que é injeção de SQL e por que é perigoso?

A injeção de SQL é um ataque frequentemente direcionado a aplicativos da web. O objetivo desse ataque frequentemente é exfiltrar dados confidenciais do banco de dados e usá-los para ganho pessoal do invasor. Tal ataque é tão prevalente e perigoso precisamente porque muitos desenvolvedores ignoram a importância da segurança ao criar soluções públicas voltadas para a web. Quando as falhas de segurança são ignoradas, as partes mal-intencionadas geralmente as encontram e exploram. Esses atores nefastos exploram essas vulnerabilidades porque podem lucrar com a venda de dados roubados durante a violação.

Os impactos de tal ataque dependem do seu aplicativo da web. Suponha que seu aplicativo não armazene informações confidenciais e, nesse caso, o ataque provavelmente não teria consequências de longo alcance. No entanto, se esse não for o caso, você pode ter um problema sério em suas mãos – dados confidenciais podem ser roubados e vendidos para obter lucro, causando problemas para seus negócios e problemas desnecessários para seus clientes devido ao estresse de redefinir senhas e alterar informações em outros lugares.

Como funciona a injeção de SQL?

O conceito de injeção de SQL é bem simples: esse ataque funciona porque alguns desenvolvedores colocam tudo o que o usuário escreve em um determinado campo de entrada em uma consulta e o repassam para um banco de dados. Um snippet básico de código vulnerável ficaria assim (você também pode usar $_GET em vez de $_POST, a premissa é a mesma):

$Input = $_POST['input'];

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

Como você pode ver, em alguns dos casos, o código vulnerável é bastante simples (também pode ficar complexo, entraremos em diferentes cenários mais tarde) – esse código vulnerável é então explorado por invasores frequentemente usando o caractere de aspas (') para induzir erros. Uma vez que induz a erros, os invasores sabem que o código é vulnerável e podem atacar nossos aplicativos.

Tipos de injeção de SQL

Existem algumas categorias em que os ataques de injeção de SQL se enquadram:

  • Injeção SQL clássica – um tipo básico de injeção SQL quando o invasor visa executar código SQL dentro de um banco de dados para obter acesso a um aplicativo ou qualquer outro sistema que tenha implementado o MySQL em sua arquitetura de banco de dados.
  • Injeção SQL baseada em união – um tipo de injeção SQL em que um invasor usa a cláusula UNION no MySQL para combinar os resultados de consultas que retornam uma resposta útil para o invasor.
  • Injeção de SQL baseada em erro – um tipo de injeção de SQL em que o invasor coleta dados principalmente por meio de mensagens de erro exibidas (ou ausentes) no aplicativo que está sendo atacado. A injeção de SQL baseada em erros tem alguns tipos por si só.
  • Injeção de SQL fora de banda (OOB) – um tipo de injeção de SQL em que um invasor não pode usar o mesmo aplicativo para atacar e coletar resultados. Um tipo menos conhecido de injeção de SQL, mas ainda assim um tipo.

Os invasores usam cada um dos tipos descritos acima para atingir objetivos diferentes – a injeção SQL clássica é útil se o invasor tiver algum conhecimento implícito sobre o funcionamento interno do sistema, a injeção SQL baseada em união pode ser útil se o invasor combinar os resultados de alguns de SELECTinstruções em um único conjunto de resultados, a injeção de SQL baseada em erros é usada quando o aplicativo é "silencioso" (o que significa que ele não retorna nenhuma resposta, portanto, o invasor procura alterações de funcionalidade ao emitir determinados tipos de consultas)

Protegendo seu aplicativo contra injeção de SQL

Neste ponto, você deve ter uma boa compreensão do que é injeção de SQL e quais são seus tipos, mas como proteger seus aplicativos de tal ataque? Felizmente, existem algumas maneiras bem conhecidas de diminuir o risco de tal vulnerabilidade ser explorada agora ou no futuro:

  • Mantenha todos os componentes do aplicativo atualizados e instale todos os patches de segurança necessários – manter os componentes do aplicativo atualizados deve ser uma primeira linha de defesa eficaz contra qualquer ataque.
  • Validar entrada – como o sucesso de tal ataque depende muito da entrada que o invasor fornece ao sistema, a validação de entrada pode ser outra maneira bem-sucedida de evitar ataques de injeção de SQL agora e no futuro.
  • Use instruções parametrizadas – o uso de instruções parametrizadas talvez seja a maneira mais eficaz de se defender contra ataques de injeção de SQL. Quando instruções parametrizadas estão em uso, o servidor sempre interpreta a entrada do usuário como um valor e não a analisa. Por exemplo:
/* 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 um firewall de aplicativo da Web – usar um firewall de aplicativo da Web (WAF) é outra linha de defesa eficaz porque os firewalls de aplicativo da Web geralmente são capazes de identificar e bloquear vários tipos de ataques, incluindo injeção de SQL, script entre sites, falsificação de solicitação entre sites , controle de acesso quebrado, exposição de dados confidenciais, ataques DoS ou DDoS, entre outros. Idealmente, um firewall de aplicativo da Web deve ser usado com instruções parametrizadas para máxima eficiência e defesa contra injeção de SQL e outros tipos de ataques.
  • Use aplicativos focados em segurança fornecidos pelo MySQL ou outros fornecedores – o MySQL oferece uma maneira de proteger seus aplicativos contra injeção de SQL no nível corporativo usando uma ferramenta MySQL Enterprise Firewall, que pode fornecer proteção em tempo real contra ameaças específicas de banco de dados. Além disso, vale a pena discutir mais sobre vários outros fornecedores (além do MySQL, alguns deles incluem MariaDB, MinervaDB, MongoDB, Oracle, Variousnines e outros). Ainda assim, para esta postagem no blog, não vamos entrar em muitos detalhes.
  • Evite conceder privilégios administrativos quando não forem necessários – evitar conceder privilégios desnecessários pode ser uma fortaleza eficaz contra muitos tipos de ataques, incluindo escalação de privilégios e, claro, injeção de SQL. Por exemplo, se o usuário que usa seu aplicativo precisar apenas de determinados direitos de acesso, considere conceder apenas as permissões necessárias para concluir as tarefas. Impor a regra de privilégio mínimo no nível do banco de dados também é uma excelente ideia.

Manter esses pontos em mente deve ajudar a manter seu aplicativo funcionando bem.

Protegendo seu banco de dados contra injeção de SQL

Usar declarações preparadas, usar plugins focados em segurança fornecidos pelo MySQL, evitar conceder privilégios administrativos desnecessários e levar em consideração outras precauções mencionadas acima devem colocar você e seu banco de dados em um bom caminho. No entanto, se você quiser se aprofundar no MySQL e entender por que as consultas SQL funcionam da maneira que funcionam e por que usar um, por exemplo, um firewall de aplicativo da Web (WAF) pode protegê-lo contra vários tipos de ataques, incluindo injeção de SQL, considere o seguinte:

  • Pense em cada consulta como uma grande tarefa composta de tarefas menores.
  • As tarefas da consulta podem ser observadas executandoSHOW PROFILE FOR QUERY [query id here];

Se usado corretamente, na maioria dos casos, a saída fornecerá o que a consulta fez e a duração da tarefa. Você também poderá observar um monte de coisas interessantes, incluindo obter respostas para perguntas como:

  • Quanto tempo levou para iniciar a consulta?
  • Quanto tempo a consulta levou para verificar as permissões?
  • Quanto tempo levou para o MySQL abrir tabelas?
  • Quanto tempo levou para o MySQL inicializar os processos?
  • Quanto tempo levou para o MySQL otimizar, preparar e (ou) executar a consulta?
  • Quanto tempo levou para o MySQL enviar os dados de volta para você ser visualizado?
  • Quanto tempo levou para o MySQL encerrar a consulta, fechar tabelas, liberar itens?

Algumas das respostas a essas perguntas podem ajudá-lo a entender por que a injeção de SQL funciona da maneira que funciona. Por exemplo, emita uma SHOW PROFILE FOR QUERYconsulta novamente e você verá o seguinte:

Uma parte da saída da consultaSHOW PROFILE FOR QUERY

A linha marcada indica que logo após iniciar a execução da consulta, o MySQL verifica as permissões. Lembra do que discutimos anteriormente? Você deve evitar conceder privilégios desnecessários precisamente por esse motivo – se a conta MySQL que um invasor está mirando não tiver permissões suficientes, a consulta falhará. Como a funcionalidade das SHOW PROFILE FOR QUERYconsultas não está no escopo desta postagem do blog, não entraremos em muitos detalhes aqui, mas você pode ver como e por que seguir os conselhos acima é importante.

A maioria dos conselhos descritos acima também é aplicável no espaço do banco de dados:

  • Manter todos os componentes do seu aplicativo atualizados inclui o phpMyAdmin.
  • Validar entrada inclui validar todas as entradas, não apenas validar entradas que fazem parte de algo.
  • As instruções parametrizadas podem (e devem) ser usadas em todas as ocasiões em que as consultas SQL são usadas para evitar a exfiltração de dados de determinadas tabelas.
  • Usar um firewall de aplicativo da Web e usar plug-ins com foco em segurança pode impedir que invasores obtenham acesso ao seu banco de dados.
  • Evitar conceder muitos privilégios também pode salvar seu banco de dados do desastre (consulte o exemplo acima)

Leve em consideração os conselhos acima e você deve estar no caminho certo para mitigar os problemas de injeção de SQL que podem atingir seu banco de dados agora ou no futuro.

Resumo

Como você pode dizer, a maioria dos conselhos que ajudam a proteger seus aplicativos e bancos de dados da injeção de SQL é bastante geral e direto. No entanto, proteger seus bancos de dados da injeção de SQL também não é ciência de foguetes – mantenha as diretrizes descritas acima em mente e você deve estar pronto! 

Fonte: 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