Project 31-A

 Disclaimer: All opinions in this post are mine and not my employer (Microsoft). If you know of a more correct or performant way to accomplish work discussed in this post, please let me know at email javascript-developer@outlook.com . Many projects I work on are in progress by the time I work on them. I can't change previous design or architecture choices, but just solve a specific technical issue.  Secrets stored in Azure Key Vault All secrets for the React app are stored in Azure Key Vault. These secrets need to be pulled from Key Vault and set into the environment so that the `npm build` script uses those values. In order for the Azure DevOps Pipeline to connect to Azure Key Vault, you need to complete some work before you develop your Pipeline: Create a Key Vault and store your React build secrets, such as an Azure Functions key, used to authenticate and use the Function. Your secret doesn't have to have the same name as your React build variable. Please don't try. Ke

I recently moved an Azure SQL database back to a local development database and ran into a few issues. I took these notes so that they might help the next person that hits the problem. In my local SSMS, I use the Import/Export wizard with the datasource using SQL Server native client 11.0. This moves the tables and data. Any destination tables will not have IDENTITY as the source tables did.  Solution # 1  Move away from INT Identity to use GUIDS. This requires work in the database and client code but is the better choice if you need to move data out of the source datatabase then back into the source database.  Solution #2 More immediate fix to get past the block that your inserts don't autoincrement.  Steps: The following steps are completed in SSMS in the destination (local) database and should have all the data but not the IDENTITY column. Rename the mytable to mytable2. Generate CREATE, INSERT, and SELECT scripts for the table. Modify the CREATE script to use the table name (ch