Automatic updates are configured by default for each Azure SQL database, allowing you to perform a point-in-time restore of the database to any point within the configured retention period. Although the restore process is documented, I still had some doubts when replacing the existing database with the one from the backup, so I am documenting the steps I took for future reference.
I recently had to create a copy of multiple Azure SQL databases. They were all interconnected, i.e. each database had some other databases registered as external data sources. After the import, these data sources had to be updated with new database locations and credentials.
In a recent discussion of pros and cons of using EF Core in-memory database provider for testing, the idea of using SQL Server Express LocalDB instead came up. I remembered reviewing an article about this last year. But after reading it once again, it turned out that some work would still be required to create a working sample.
DateTime can be a tricky data type to deal with. Not only is there daylight saving time and different time zones to keep in mind but also the range and precision can vary in different systems. You are probably already aware of some differences between .NET framework's DateTime structure in Transact-SQL's datetime data type. You might not be aware of the difference in precision between these two data types, though.
Using information schema views and the fn_listextendedproperty function I wrote a table valued function which returns information about all the columns in the given table. I'm posting it here in case someone else finds it useful.
As soon as a pooled connection with enabled application role gets reused an exception gets thrown and its description is not really helpful if you're not aware of the problem: General Network Error. This happens because the security context of the connection doesn't get properly reset when it is closed.
SQL Server's common data type datetim` for both date and time values can be a source of quite some confusion. The decision on whether to store them separate or joined can depend on many factors, but sooner or later the need for separating or joining the date and time parts will arise.
The following query is a good starting point if you want to export the SQL Server Agent job history to a file and you're still using Enterprise Manager from SQL Server 2000.