Microsoft ADO.NET driver for SQL Server

Microsoft ADO.NET driver for SQL Server aka the Microsoft.Data.SqlClient GitHub repository.

Microsoft.Data.SqlClient is a data provider for Microsoft SQL Server and Azure SQL Database. Now in General Availability, it is a union of the two System.Data.SqlClient components which live independently in .NET Framework and .NET Core. Going forward, support for new SQL Server features will be implemented in Microsoft.Data.SqlClient

https://github.com/dotnet/SqlClient

https://dpaoliello.wordpress.com/

Standalone SQL Server Integration Services (SSIS) DevOps Tools

Standalone SSIS DevOps Tools provide a set of executables to do SSIS CICD tasks. Without the dependency on the installation of Visual Studio or SSIS runtime, these executables can be easily integrated with any CICD platform. The executables provided are:

SSISBuild.exe: build SSIS projects in project deployment model or package deployment model.
SSISDeploy.exe: deploy ISPAC files to SSIS catalog, or DTSX files and their dependencies to file system.

https://techcommunity.microsoft.com/t5/sql-server-integration-services/standalone-sql-server-integration-services-ssis-devops-tools-in/ba-p/1782270

ASQA Analysis Services Query Analyzer

Looks a little outdated at first…

Troubleshooting MDX queries can be a complex and time-consuming activity that requires the manual execution of many and repetitive tasks using different tools. Using Analysis Services Query Analyzer, you can forget all the complexities and drastically reduce the time spent to execute your analysis.

https://ssasqueryanalyzer.github.io/

Analysis Services Query Analyzer (ASQA) is a complete FREE tool distributed under the MIT license and its source code is published on GitHub https://github.com/SSASQueryAnalyzer/SSASQueryAnalyzer

MDX Studio

MDX Studio is a tool that was developed by Mosha Pasumansky, a former Analysis Services developer.
This tool is invaluable when writing a MDX query: you have a code formatting feature, an embedded system to analyze query performance and many other features for writing MDX queries.

Unfortunately, the source code is not publicly available and the project is currently no longer being updated by Mosha. Other contributors made an effort to keep the tool compatible with newer versions of Analysis Services and client connection libraries.

https://www.sqlbi.com/tools/mdx-studio/

Konsole V6

Low ceremony, Fluent DSL for writing console apps, utilities and spike projects. Providing thread safe progress bars, windows and forms and drawing for console applications. Build UX’s as shown below in very few lines of code. Konsole provides simple threadsafe ways to write to the C# console window.

https://github.com/goblinfactory/konsole

Integration Services Programming Overview

SQL Server Integration Services has an architecture that separates data movement and transformation from package control flow and management. There are two distinct engines that define this architecture and that can be automated and extended when programming Integration Services. The run-time engine implements the control flow and package management infrastructure that lets developers control the flow of execution and set options for logging, event handlers, and variables. The data flow engine is a specialized, high performance engine that is exclusively dedicated to extracting, transforming, and loading data. When programming Integration Services, you will be programming against these two engines.

https://docs.microsoft.com/en-us/sql/integration-services/integration-services-programming-overview?view=sql-server-ver15
Integration Services architecture

In this article, we will first illustrate how to create, save and execute SSIS packages using ManagedDTS in C#, then we will do a small comparison with Biml.

https://www.sqlshack.com/biml-alternatives-building-ssis-packages-programmatically-using-manageddts/
https://www.sqlshack.com/biml-alternatives-building-ssis-packages-programmatically-using-manageddts/

Why I No Longer Use MVC Frameworks

The worst part of my job these days is designing APIs for front-end developers. The conversation goes inevitably as:
Dev – So, this screen has data element x,y,z… could you please create an API with the response format {x: , y:, z: }
Me – Ok
I don’t even argue anymore. Projects end up with a gazillion APIs tied to screens that change often, which, by “design” require changes in the API and before you know it, you end up with lots of APIs and for each API many form factors and platform variants. Sam Newman has even started the process of institutionalizing that approach with the BFF pattern that suggests that it’s ok to develop specific APIs per type of device, platform and of course versions of your app. Daniel Jacobson explains that Netflix has been cornered to use a new qualifier for its “Experience APIs”: ephemeral. Sigh…

https://www.infoq.com/articles/no-more-mvc-frameworks/