Introduction

An Azure SQL Server failover group is a group of databases that can be automatically or manually failed over from a primary server to a secondary server in a different Azure region in case of a disaster in the primary server. Failover groups provide high availability and disaster recovery for Azure SQL Server databases.

The process described in this post is composed by two main steps:

• Provisioning the database
• Adding the database to the failover group

Provisioning the database

The first step is to create the database. This step is composed by the following actions:

• Get the tenant information
• Create the database

Tenant information class:

Code to create database programatically:

Adding the database to the failover group

The second step adds the newly created database to the failover group. This step is composed by the following actions:

• Get the failover group where we want to add the database
• Re-add the existing databases to the failover group – necessary since when we get the failover group the list of databases of the group is empty and, without this step, the failover group would only have the new database
• Add the new database to the failover group

Other Articles

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you want to learn how to develop SPFx solutions, click here.

If you want to learn how you can rename a modern SharePoint site, click here.

If you want to learn how to save time time scheduling your meetings, click here.

If you want to learn how to enable Microsoft Teams Attendance List Download, click here.

If you want to learn how to create a dynamic org-wide team in Microsoft Teams with all active employees, click here.

If you want to modernize your SharePoint classic root site to a modern SharePoint site, click here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If you prefer to use the traditional method to update your farm and want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated, click here.

If you want to learn how to upgrade a SharePoint 2013 farm to SharePoint 2019, click here and here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, click here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from Ignite and some more recent announcements, including Microsoft Search, What’s New to Build a Modern Intranet with SharePoint in Office 365, Deeper Integration between Microsoft Teams and SharePoint and the latest news on SharePoint development, click here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy Coding!

The post Provision a database programmatically in Azure SQL database with a failover group appeared first on Blog IT.

I will introduce a small usage sample for the JSON_VALUE function in combination with indexes to improve information retrieval from a table containing one JSON object. For our testes, we have a UserDetailTest table that has more than 500k rows with 2 columns: an UserId and a nvarchar(max) to hold a small JSON details string like the following:

SELECT *, LEN(DetailsJSON) AS [Len(DetailsJSON)] FROM UserDetailTest

I will activate time statistics and clean SQL Server cache between each query to have some consistency across the execution times using the following SQL statements:

CHECKPOINT
DBCC DROPCLEANBUFFERS
SET STATISTICS TIME ON

JSON_VALUE Function intro

The JSON_VALUE function extracts a value from a JSON string. This functions receives 2 arguments, the first being an expression for the JSON value and the second a path for the value we want to obtain. A simple sample with an inline JSON object would be the following:

SELECT JSON_VALUE('{"PostalCode":"376-3765","PhoneNumber":"351003765718"}', '$.PhoneNumber')

The return is a scalar value (nvarchar(4000)) for the PhoneNumber element.

Query scenarios

Starting with one of the really worst case scenario (yes, this can happen…):

More than 17 seconds really seems like a worst scenario! Next, we will use the JSON_VALUE function to get the PhoneNumber from the JSON string and use it in our where clause:

This still takes more than 3 seconds. A good improvement, but yet a high cost if we need to search information in this way.

Index creation

Let’s add a new virtual column to table that displays the result from the JSON_VALUE function – this will allow us to create an index and simplify the SELECT queries.

ALTER TABLE UserDetailTest 
	ADD vPhoneNumber AS 
	CAST(JSON_VALUE(DetailsJSON, '$.PhoneNumber') AS NVARCHAR(255));

The cast truncates the output from the JSON_VALUE to ensure that it does not exceed the maximum lenght for the index key. Now, if we search using the column, the result is still more or less the same 3 seconds has before:

Let’s create an index and perform the search again:

CREATE INDEX idx_vPhoneNumber ON [UserDetailTest] (vPhoneNumber);

Consequently the improvement is huge, 13 miliseconds is more interesting! But what’s the cost?

The cost

When we create an index, we’re basically trading space for time – more occupied space versus faster operations. Therefore let’s see what the increase is using sp_spaceused function before and after index creation:

Probably, an interesting comparison would be if the PhoneNumber column was an explicit column in that table containing the value. Let’s do that!

ALTER TABLE UserDetailTest  
	ADD PhoneNumberCopy NVARCHAR(255)

UPDATE UserDetailTest
	SET PhoneNumberCopy = vPhoneNumber

The sp_spaceused remained the same – SQL Server internal black magic regarding space allocation (for another time!). But performance wise, for this approach in my machine this query still took more than 2 seconds to complete:

Slightly better than the query with the JSON function but the advantage is that in this scenario SQL can better optimize the searches. The following runs of the same query without clearing the cache returns results much faster – each took around 220 miliseconds to complete:

Summary Results

Just to sum up all the results for the different types of searches comparing the first execution after cache clean up and the following runs. I did several iterations for each step just to make sure the results were consistent although the goal was just to have a baseline. Certanly, the use of this will depend on each case.

WHERE DetailsJson LIKE '%PhoneNumber":"351003765718"%'

WHERE JSON_VALUE(DetailsJson, '$.PhoneNumber') = '351003765718'

WHERE vPhoneNumber = '351003765718'

WHERE vPhoneNumber = '351003765718'

WHERE PhoneNumberCopy  = '351003765718'

The post Query performance for JSON objects inside SQL Server using JSON_VALUE function appeared first on Blog IT.

Imagine you have this table

CREATE TABLE VerticalTable
(
Id int,
Att_Id varchar(50),
Att_Value varchar(50)
)

INSERT INTO VerticalTable
SELECT 1, 'FirstName', 'John' UNION ALL
SELECT 1, 'LastName', 'Smith' UNION ALL
SELECT 1, 'Email', 'john.smith@dummy.com' UNION ALL
SELECT 2, 'FirstName', 'Jack' UNION ALL
SELECT 2, 'LastName', 'Daniels' UNION ALL
SELECT 2, 'Email', 'jack.daniels@dummy.com'

If you run

SELECT * FROM VerticalTable

you get this

To convert this into an horizontal table I’m going to use PIVOT.

SELECT [Id], [FirstName], [LastName], [Email] 
FROM
(
 SELECT Id, Att_Id, Att_Value FROM VerticalTable
) as source
PIVOT
(
 MAX(Att_Value) FOR Att_Id IN ([FirstName], [LastName], [Email])
) as target

And I will get this

You can find the code here.

The post Converting a Vertical Table to an Horizontal Table in SQL Server appeared first on Blog IT.

Here you can check the requirements to create a persisted  computed column on SQL Server.

“…the SET options in the following table must be set to the values shown in the Required value column…”

The post SQL Persisted Computed Column ANSI_NULLS appeared first on Blog IT.

USE AdventureWorks2012;
GO
SELECT BusinessEntityID, YEAR(QuotaDate) AS SalesYear, SalesQuota AS CurrentQuota, 
       LAG(SalesQuota, 1,0) OVER (ORDER BY YEAR(QuotaDate)) AS PreviousQuota
FROM Sales.SalesPersonQuotaHistory
WHERE BusinessEntityID = 275 and YEAR(QuotaDate) IN ('2005','2006');

LEAD – http://msdn.microsoft.com/en-us/library/hh213125.aspx

USE AdventureWorks2012;
GO
SELECT BusinessEntityID, YEAR(QuotaDate) AS SalesYear, SalesQuota AS CurrentQuota, 
    LEAD(SalesQuota, 1,0) OVER (ORDER BY YEAR(QuotaDate)) AS NextQuota
FROM Sales.SalesPersonQuotaHistory
WHERE BusinessEntityID = 275 and YEAR(QuotaDate) IN ('2005','2006');

SQL SERVER 2012 and 2014

The post How to Access the Previous Row and Next Row value in SELECT statement? appeared first on Blog IT.

Strange behavior will occur if the datasources aren’t sorted equal by the same key.

http://msdn.microsoft.com/en-us/library/ms141775.aspx

“The Merge Join Transformation requires sorted data for its inputs.”

http://msdn.microsoft.com/en-us/library/ms137653.aspx

The post Strange behavior with “Merge Join” in SSIS appeared first on Blog IT.

My session was entitled SharePoint Tunning, focused on techniques used to improve the performance of a SharePoint farm. The main topics of the session were:

• SQL Server performance tips (most of the presentation, since performance in SharePoint is guaranteed mainly at SQL Server level)
• SharePoint farm performance tips
• SharePoint development tips

You can find the slide deck here. I hope you understand Portuguese since the slide deck is in my mother language :).

Related Links:

• Portuguese SharePoint Community web site
• My SlideShare web site
• |create|it| web site

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint farm in an automated way using PowerShell, I invite you to click here and here. The articles use AutoSPInstaller with a SharePoint 2016 farm but AutoSPInstaller support for SharePoint 2019 was already announced!

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

UPDATE 01/11/2018:

If you or your customers are not ready to move entirely to the Cloud and Office 365, a hybrid scenario could be an interesting scenario and SharePoint 2019 RTM was recently announced with improved hybrid support! To learn all about SharePoint 2019 and all its features, click here.

UPDATE 21/11/2018:

If you want to know all about the latest SharePoint and Office 365 announcements from Ignite and some more recent announcements, including Microsoft Search, What’s New to Build a Modern Intranet with SharePoint in Office 365, Deeper Integration between Microsoft Teams and SharePoint and the latest news on SharePoint development, click here.

Happy SharePointing!

The post SharePoint Tunning Session appeared first on Blog IT.

I used the following commando to view the current identity value:

DBCC CHECKIDENT ('TableName1', NORESEED)

and then, it returned the following message:

Checking identity information: current identity value '53', current column value '53'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Finally, after I've checked the current identity value, i needed to reset this value and I've used the following command:

DBCC CHECKIDENT (TableName1, RESEED, 0)

and then, it returned the following message: 

Checking identity information: current identity value '53', current column value '0'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

The post Reset Identity value appeared first on Blog IT.

O Sql Server possui um mecanismo de pesquisa de texto com base na indexação de colunas de tabelas numa base de dados chamado Full-Text Search. Este mecanismo de pesquisa utiliza um catálogo de pesquisa, criado no file system, e tem uma série de vantagens relativamente às pesquisas que utilizam o predicado LIKE, entre as quais se destacam:

• Mecanismo de pesquisa mais rápido, nomeadamente em tabelas com um grande volume de dados;
• Possibilidade de indexar colunas do tipo image. Desta forma, torna-se possível efectuar pesquisa de texto dentro de documentos armazenados em base de dados;
• Possibilidade de realizar pesquisas específicas para um idioma;
• Possibilidade de incluir noise words (por idioma), um conjunto de palavras que são ignoradas numa query utilizando FTS.

Tal como referido anteriormente, o Full-Text Search usa um catálogo de pesquisa, criado no file system, para cada base de dados, onde são definidas as tabelas e respectivas colunas a indexar. Depois de criado o catálogo e para poderem ser efectuadas pesquisas sobre o mesmo, deve-se proceder à sua população. Existem duas opções de população de um catálogo de pesquisa:

• Full Population – efectua uma população completa do catálogo de pesquisa, ou seja, são criadas entradas no índice para todas as linhas de dados das tabelas do catálogo. Deve ser executada uma vez, na primeira população do catálogo;
• Incremental Population – efectua a actualização do catálogo com base nas alterações efectuadas desde a última população às tabelas que fazem parte do catálogo. Deve ser executada periodicamente, tipicamente 1 vez por dia.

Para se proceder à actualização do catálogo de pesquisa com uma determinada periodicidade, deve ser criado um schedule. Este procedimento dará origem à criação de um Job (é necessário ter o serviço Sql Server Agent a correr) que na periodicidade definida no schedule executará uma stored procedure de sistema (sp_fulltext_catalog) para actualizar o catálogo. O exemplo seguinte utiliza a base de dados Northwind e um catálogo chamado Northwind_Catalog:

use Northwind exec sp_fulltext_catalog ‘ Northwind_Catalog ‘, ‘start_incremental’

Actualização de múltiplos cátalogos de pesquisa

O exemplo apresentado anteriormente demonstra a utilização de catálogos de pesquisa Full-Text Search numa base de dados Sql Server. Num cenário de um sistema de informação que possua várias bases de dados de conteúdos, controlados por uma base de dados de configuração, e se pretenda actualizar de forma periódica os catálogos de pesquisa de todas as bases de dados, pode ser actualizado um mecanismo idêntico ao apresentado de seguida.

O exemplo seguinte pressupõe a existência de uma base de dados de configuração onde é armazenada a informação sobre todas as bases de dados de conteúdos existentes no sistema. Esta informação é guardada numa tabela chamada ContentDatabases com a seguinte estrutura:

• ID – campo identity (chave primária da tabela)
• Name – campo onde é guardada a informação do nome da base de dados de conteúdos
• …

O nome do catálogo de pesquisa em cada base de dados de conteúdos é ContentDatabase_Catalog.

A actualização dos catálogos de pesquisa será efectuada por intermédio de uma stored procedure criada na base de dados de configuração chamada UpdateContentDatabasesCatalogs. A stored procedure é criada da seguinte forma:

CREATE PROCEDURE [dbo].[UpdateContentDatabasesCatalogs]
AS
    DECLARE @ID int
    DECLARE @Name nvarchar(50)
    DECLARE @sqlStatement nvarchar(250)

    SELECT @ID = MIN(ID) FROM [ContentDatabases]

    while @ID is not null
    begin
        SELECT @Name = [Name] FROM [ContentDatabases] WHERE ID = @ID
        SET @sqlStatement = ‘use ‘ + @Name + ‘ exec sp_fulltext_catalog N”ContentDatabase_Catalog”, N”start_incremental”’
        exec sp_executesql @sqlStatement
        SELECT @ID = min(ID) FROM [ContentDatabases] WHERE ID > @ID
    end
GO

Para finalizar, deve ser criado um Job no Sql Server para executar esta stored procedure com a periodicidade desejada.

Recursos

Para saberem mais sobre Full-Text Search podem consultar os seguintes artigos:

• SQL Server 2005 Full-Text Search: Internals and Enhancements
• Full-Text Search Architecture
• Administering Full-Text Search

The post Full-Text Search: Actualizar múltiplos cátalogos de pesquisa appeared first on Blog IT.

Let's see how we can retrieve all the employees that report to a manager (ManagerID = 3) in the AdventureWorks database sample:

WITH CTE (EmployeeID, FullName, Title, ManagerID) AS
(

SELECT E.EmployeeID, C.FirstName + ' ' + C.LastName FullName, E.Title, E.ManagerID
FROM HumanResources.Employee E
INNER JOIN Person.Contact C ON E.ContactID = C.ContactID
WHERE E.EmployeeID = 3
UNION ALL

SELECT E.EmployeeID, C.FirstName + ' ' + C.LastName FullName, E.Title, E.ManagerID
FROM HumanResources.Employee E
INNER JOIN Person.Contact C ON E.ContactID = C.ContactID
INNER JOIN CTE ON E.ManagerID = CTE.EmployeeID
)

SELECT * FROM CTE

This query returns the following results:

If we don't want to return the manager we change the WHERE clause:

WITH CTE (EmployeeID, FullName, Title, ManagerID) AS
(

SELECT E.EmployeeID, C.FirstName + ' ' + C.LastName FullName, E.Title, E.ManagerID
FROM HumanResources.Employee E
INNER JOIN Person.Contact C ON E.ContactID = C.ContactID
WHERE E.ManagerID = 3
UNION ALL

SELECT E.EmployeeID, C.FirstName + ' ' + C.LastName FullName, E.Title, E.ManagerID
FROM HumanResources.Employee E
INNER JOIN Person.Contact C ON E.ContactID = C.ContactID
INNER JOIN CTE ON E.ManagerID = CTE.EmployeeID
)

SELECT * FROM CTE

And the results are:

If we want to get all the employees that an employee reports to, we just have to change the INNER JOIN order:

WITH CTE (EmployeeID, FullName, Title, ManagerID) AS
(

SELECT * FROM CTE

And the employees that the employee (EmployeeID = 3) reports to are:

The post Recursive Queries in SQL Server 2005 appeared first on Blog IT.