In SQL Server, you can use the CONVERT() function to convert an expression of one data type to another. Therefore, if you need to convert a string to a date/time format, this function can help.
This article contains examples to demonstrate its usage.
Starting with SQL Server 2012, the EOMONTH() function allows you to find the last day of any given month. It accepts two arguments; one for the start date, and one optional argument to specify how many months to add to that date.
This article provides examples that demonstrate how EOMONTH() works in SQL Server.
Transact-SQL includes a bunch of functions that help us work with dates and times. One of the more common tasks when working with dates is to extract the different parts of the date. For example, sometimes we only want the year, or the month. Other times we might want the day of the week. Either way, there are plenty of ways to do this in SQL Server.
In particular, the following functions allow you to return the day, month, and year from a date in SQL Server.
These functions are explained below.
This article provides a solution to a problem you may occasionally encounter while using the DATEDIFF() function in SQL Server.
If you encounter the following error:
The datediff function resulted in an overflow. The number of dateparts separating two date/time instances is too large. Try to use datediff with a less precise datepart.
It’s because the return value is too large. The DATEDIFF() function returns its result as an int data type. The reason you got this message is that the return value is too big for the int data type. Fortunately there’s an easy way to fix this.
When querying a SQL Server database, there may be times where you don’t want null values to be returned in your result set. And there may be times where you do want them returned. But there may also be times where you do want them returned, but as a different value.
That’s what the ISNULL() function is for.
ISNULL() is a T-SQL function that allows you to replace NULL with a specified value of your choice.
Before SQL Server 2017 came along, there wasn’t a T-SQL equivalent of the MySQL GROUP_CONCAT() function. This function allows you to return a result set as a comma-separated list, as opposed to listing each row as a separate row (as with a normal result set).
Prior to SQL Server 2017, if you wanted to put your result into a comma separated list, you’d need to find a workaround, perhaps using a combination of STUFF() and FOR XML PATH().
However, T-SQL now has the STRING_AGG() function which is available from SQL Server 2017. This function does pretty much the same thing as MySQL’s GROUP_CONCAT() function (with some minor differences).
Starting with SQL Server 2017, you can now make your query results appear as a list. This means you can have your result set appear as a comma-separated list, a space-separated list, or whatever separator you choose to use.
While it’s true that you could achieve this same effect prior to SQL Server 2017, it was a bit fiddly.
Transact-SQL now has the STRING_AGG() function, which concatenates the values of string expressions and places separator values between them. This works in much the same way to MySQL’s GROUP_CONCAT() function.
This article provides examples that demonstrate the T-SQL STRING_AGG() function.
In MySQL, you can return your query results as a comma separated list by using the GROUP_CONCAT() function.
The GROUP_CONCAT() function was built specifically for the purpose of concatenating a query’s result set into a list separated by either a comma, or a delimiter of your choice.
This article provides examples of how it all works.
Continue reading
When working with databases, sometimes you want to find out how many rows will be returned by a query, without actually returning the results of the query. Or sometimes you might just want to find out how many rows are in a given table.
In SQL Server, you can use T-SQL‘s COUNT() function to return the number of rows that would be returned in a query.
In MySQL, you can check the size of all tables within a given database (or on all databases) by querying the information_schema.tables table. This table stores data about each table in a database, including information about each table’s size, creation date, collation, etc.
You can also find the size of each table within a database by using the MySQL Workbench GUI.
This article provides a quick overview of each method.