Error codes in SQL are generated by the server to provide information about what has gone wrong. They have different meanings depending on the SQL version you’re using, but they usually indicate the inability to perform a requested operation.
User-defined functions in SQL Server (UDFs) are key objects that each developer should be aware of. Although they are very useful in many scenarios (WHERE clauses, computed columns, and check constraints), they still have some limitations and bad practices that can cause performance issues. Multi-statement UDFs might incur significant performance impacts, and this article will specifically discuss these scenarios.
Nowadays, within the SQL Server DBA community, it is extremely likely that we use, or at the very least have heard of, the famous stored procedure sp_WhoIsActive developed by Adam Machanic.
During my time as a DBA, I used the SP to immediately check what’s going on inside a particular SQL Server instance when it is getting all the “finger-pointing” that a particular application is running slow.
However, there are occasions where such issues become recurring and require a way to capture what’s going on to find a potential culprit. There are also scenarios where you have several instances serving as the backend for 3rd party applications. The Stored Procedure could work potentially well to find our culprits.
SQL Server is one of the most popular databases used in modern applications. Over the past few decades, it has established itself as a leading database provider that drives most of the applications in the Microsoft ecosystems. It provides unique features and easy integration with technologies.
A synonyms in SQL Server are database objects that give an alternative name to the database objects existing locally or on the remote server. Also, they provide an abstraction layer to protect the application from any changes in the base object.
If you deal with SQL infrastructure, especially Microsoft SQL Servers, you deal with SSMS. The SQL Server Management Studio is the default choice for all professionals working with databases. It is not the only option, but it is the leader, backed by Microsoft and equipped with all the necessary SQL Server developer tools.
Still, even with all its advantages, SSMS is not perfection. It needs improvements as it often lacks the necessary or simply helpful functionality. Most SQL specialists inevitably get into situations where SSMS can’t do what they need. Or can’t do it how they want.
SQL Server Transactional Replication is one of the most common Replication techniques used to share, copy, or distribute data to multiple destinations. In this article, we will discuss Replication, various Replication Types, and pay special attention to the Transactional Replication work.
Today’s article comes from a scenario we experienced in practice some time ago. We managed a card transaction system referred to as Postilion, and we had to update the data in a column containing IP addresses as part of the string with a new IP address. This was necessary because the IP address of the server hosting the solution would typically change due to switchover or the data restore to a UAT environment.
The data about the server was stored in the databases, and there was no way to update the same from the application without going row by row. Thus, we had to come up with an efficient solution using the LEN and SUBSTRING (or REPLACE) SQL Server functions.
To insert data into a table having columns with default constraints, we can use the DEFAULT constraint to a default value in a table. This article will cover the following aspects:
No matter how hard we try to design and develop applications, errors will always occur. There are two general categories – syntax or logical errors can be either programmatic errors or consequences of incorrect database design. Otherwise, you might get an error because of the wrong user input.
