SQL Server 2016 and Azure SQL Database both give you tables that automatically keep track of the history of your data. Here's how to retrieve that historical data.
SQL Server 2016 and Azure SQL Database both give you tables that automatically keep track of changes to your data. Here's how to both create those tables and alter existing tables so they track the history of your data.
With SQL Server 2016, you can store JSON objects in your rows. Here’s how to work with JSON objects, including how to update them once you’ve found them.
When it comes to inheritance, relational database theory and object-oriented programming have more in common than you might think. Understanding that overlap is critical in designing the object model that will generate the database design your application needs.
With SQL Server 2016, it now makes sense to store JSON objects in your database (even though there’s no JSON datatype). Here’s how to query JSON properties to find the rows you want.
See how the latest version of Visual Studio 2017 can be used to create Azure Functions using familiar development tools and techniques.
- By Jason Roberts
There’s a potential security exploit that ASP.NET MVC leaves you open to. However, in Peter’s opinion, all the proposed solutions miss the point.
Encrypting data that you want stored in your View and returned to you when the user clicks the Submit button has its own special problems. Here’s a complete solution and, as a bonus, an Encryption object you can use anywhere.
SQL Server 2016 lets you treat JSON objects like rows in a table, allowing you to use data from AJAX queries in joins, updates and any other SQL statement you can think of.
When you want to return a string result -- either as text, HTML or XML -- then a ContentResult object gives you the right balance of simplicity and control.
Sometimes what you want to test is how your Action method behaves when it's invoked through an AJAX call. Here's how to mock up that call using Moq.
If you’ve been programming long enough, then you know that the "right way to do things" keeps changing. Here’s why, a description of where we are now and a guess about where we’re going.
That's often where the real problem is.
If you just want to get going with a code-first database, you don't even need to define a connection string -- just write your objects.
Your users will make mistakes ... but it would be a mistake to treat all their errors the same way. You can get more out of ASP.NET MVC's validation infrastructure just by paying attention to how you name your errors.