I wrote about Unique Keys and tried to explain how they work in one of my earlier post. It’s common to use SQL Server’s Primary Key or Unique Indexes to explain Unique Keys of Azure Cosmos DB. If you have a Primary Key in a table in SQL Server, the key you defined cannot be in that table more than once. By adding a unique index or unique constraint in a table, you guarantee that no duplicate values can be in your table. The key word in both of those statement is the TABLE.
Azure CosmosDB Unique Keys do not work like Primary Key or Unique Indexes/Constraints
Read on to learn how Cosmos DB differs.
Click through for the picture.
After all, SSMS is no longer the cool new kid on the block: Microsoft has shown consistent effort to develop their new tool, Azure Data Studio (the artist formerly known as SQL Operations Studio), since November 2017. Azure Data Studio is built on the modern foundation of Microsoft’s VS Code, whereas SQL Server Managed Studio is related to the legacy Visual Studio Shell.
Based on this overview, it might seem like a new SQL Server DBA or developer should primarily learn Azure Data Studio, not SSMS. And it might similarly seem like vendors should focus on developing new tooling only for Azure Data Studio.
But when you look into the details of how Azure Data Studio is being developed, it becomes clear that SSMS is still just as relevant than ever:
User base inertia is another reason, one that Kendra doesn’t mention directly. I like where Azure Data Studio is going and try to use it at least half-time. But there are a lot of people with a specific workflow they’ve developed and don’t want to change. As long as that’s a large percentage of the SQL Server population, SSMS isn’t going anywhere.
This is not the greatest error message.
Fortunately, I knew that I could connect to the server so the issue was not with connectivity but more around how could I authenticate against Analysis Services.
NOTE: Analysis Services can only Authenticate against domain accounts, and that is why I got the error above.
Click through for the solution.
It is common having services accounts that are job owners so they can run within the proper context.
In my humble opinion, this starts to be a little strange when it comes to modifying the agent job. It means that the service account needs permissions on agent roles and someone will need to connect to SQL Server using the service account (run as) so they can manage the agent job. It works, but not practical.
It’s not trivial, but there are roles and you can add a bit of extra code to help.
If you are storing passwords in a database, you should stop doing that immediately. We, as software developers and data professionals, should never know what passwords our customers are using. The same goes for most sensitive data: we technical staff probably don’t need to know what’s in there. Some stuff should be hashed, and some stuff should be encrypted.
There’s good advice here.
The benefit of this approach is you can leverage all the standard icons and then add you own icons as well, effectively extending the default icon set. But where can I find a list of all the names of the standard icons?
I asked this question in the Power BI Blog thread (as did some others). A list of names was provided by Francisco Mullor in the comment section of that blog post (sorry, I can’t seem to link to the exact comment). I have taken the information provided by Francisco and produced the following Power BI report.
Matt also fixes a display issue that you might run into when using these.
The dot used to represent the location is, as I’ve said before, for the current location. Our
ConvertTo-Message02script changed it’s location as part of the script.
When we used the “dot source dot location” method, we weren’t using where our function is as a frame of reference to import the other functions. We were using what directory we are currently in.