azure-sql-hyperscale-autoscaler VS SqlClient

Sample source code is available here. If you want to contribute, by adding some of the improvements described below, please feel free to do so. I'll be more than happy to accept contributions to this repo.

I will be using Dapper - a simple object mapper for .Net along with Microsoft.Data.Sql.

See the link https://github.com/dotnet/SqlClient/issues/1656

Where I'm having trouble is with this android device connecting to the local sql database at that store. I initially tried connecting directly to the db but ran into this error SQL Server pre-login handshake failed Android 5,6,8.1 · Issue #1656 · dotnet/SqlClient (github.com) - which the only workaround seems to be a dodgy way of turning off security (the DangerousClassProvider class at the bottom of the page). This does actually work but doesn't seem the best way.

I was doing some simple internal tooling with EF. You know the deal, toss in a new row into a table to do something or other, simple CRUD stuff. I was making it in WASM just for the sake of trying out the framework. Turns out this is a thing: https://github.com/dotnet/SqlClient/issues/599 , which prevents EF from running. The wiki page being referenced is gone though, so I don't know the reason why it'd be incompatible. To me it doesn't make that much sense, since a console application would be functionally the same, just outside a browser.

Is any of the columns varchar(max) or similar type? There is a known issue in SqlClient package affecting async reading of such columns.

Code samples for Json.net which as of version 13.0.2 now supports DateOnly and TimeOnly. Three code samples are used to show interactions with Bogus and Microsoft.Data.SqlClient which is most likely used to work with json data.

If you're connecting to SQL Server, connection pooling can be a common cause of apparent memory leaks. If you're opening and closing hundreds of connections, the pool may not be disposing of the connections quickly enough. Or you might be running into issues like this one. You might want to look at SqlConnection.ClearAllPools or SqlConnection.ClearPool or simply disabling connection pooling entirely in the connection string.

Really frustrating to see the amount of effort that went in to gaming those benchmarks when catastrophic performance issues in core Microsoft-authored libraries go unfixed for years. https://github.com/dotnet/SqlClient/issues/593

Until you trip over this https://github.com/dotnet/SqlClient/issues/593