I am trying to fetch server name on snowflake and it says
https://app.snowflake.com/europe-west4.gcp
When I try to connect to qliksense, the error is as follows -
"Connections are only allowed to *.snowflakecomputing.com hosts"
I believe I must've messed up the set-up somewhere but unable to figure out exactly what. This is a trial account I am exploring btw. I am newbie to snowflake and any help is appreciable. Thanks !
Finding the Region and Locator for an Account
If you can connect to your Snowflake account, you can query the following context functions to identify the region and account locator for the Snowflake account you are connected to:
CURRENT_REGION retrieves the region in which your account is located.
CURRENT_ACCOUNT retrieves the account locator.
Account URL could also be copied using Snowsight UI:
Related
Im getting an error when running Data Factory to load data into Snowflake:
ErrorCode=SnowflakeUnsupportedCouldPlatformForImport,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Snowflake only support the account hosted in azure platform while as sink connector, please make sure your account is hosted in azure, current region and platform is '',Source=Microsoft.DataTransfer.ClientLibrary,'
Does the azure blob storage (staging area for copy command) needs to be in the same region as where snowflake was provision?
In my case going to the warehouse you have configured and enabling "Auto Resume" solved the issue for me. Hope this helps someone running into this same issue.
We use Azure SQL Database, and therefore had to jump through some hoops to get cross-database queries set up. We achieved this following this great article: https://techcommunity.microsoft.com/t5/azure-database-support-blog/cross-database-query-in-azure-sql-database/ba-p/369126 Things are working great for most of our databases.
The problem comes in for one of our databases which is read-only. The reason it's read-only is b/c it is being synced from another Azure SQL Server to derive its content. This is being achieved via the Geo-Replication function in Azure SQL Database. When attempting to run the query GRANT SELECT ON [RemoteTable] TO RemoteLogger as seen in the linked article, I of course get the error "Failed to update because the database is read-only."
I have been trying to come up with a workaround for this. It appears user permissions are one of the things that do NOT sync as part of the geo-replication, as I've created this user and granted the SELECT permission on the origin database, but it doesn't carry over.
Has anyone run into this or something similar and found a workaround/solution? Is it safe/feasible to temporarily set the database to read/write, update the permission, then put it back to read-only? I don't know if this is even possible - I was told by one colleague that they think it will throw an error along the lines of "this database can't be set to read/write b/c it's syncing from another database..."
I figured out a work-around: Create a remote connection to the database on the ORIGIN server. So simple, yet it escaped me until now. Everything working great now.
When I try to export my SQL database through the Azure Portal, I get a 404 error (Entity not found to invoke export).
The weird thing is that a month ago it worked perfectly. I even wrote a little manual on how to do it as I exported it. A coworker found the issue when trying to do it herself.
I've seen somewhere that "the database name is case sensitive when using az sql db export". It's strange, because we have not changed anything, but I've taken a look at the activity log of the DB and compared the log for the last successful export with the failing ones and I do see that the references to de DB in the JSON of the activity log have a different case (the last "B" of the database name):
I can also see that the database name appears with different case in different places. If I go to the Database itself, the last "B" is in uppercase, but if I go to the SQL Server, it is in lowercase. If I connect to the database from SSMS, it's lowercase too. I guess its correct name is with a lowercase b...
Anyway, I'm pretty sure we haven't changed it. In fact, in the "manual" I did a month ago I can see screenshots with the same case mismatch.
Anyone knows how to fix this issue?
I think the error is happened in Azure backend, because we did nothing for the database.
We can not help you to fix the error. Only the Azure support can help you. According my experience, Azure still have some bugs for now.
Ask Azure support like this in Portal, you can follow my example:
New support request:
Basics:
Azure will give some Solutions you can reference, just click next Details, give the more details or error screenshot for Azure.
Create the request, and wait the Azure support engineer contact you with Email or Phone.
Hope this helps.
I am currently setting up our second Azure Search service. I am making it identical to our existing one, just in a different region.
I'm using the portal Import Data function to set up my index. For the Data Source, I have configured it to connect to my Azure SQL Database and table, which definitely has Integrated Change Tracking turned on. Further, it's the exact same database and table that I'm connected to and indexing from in my existing Azure Search service.
The issue is that when I get to the "Create an Indexer" step, I get the message that says "Consider enabling integrated change tracking on your database..." In other words, it doesn't think I have change tracking on this database. I definitely do, and our other Azure Search Service recognizes this just fine on the exact same database.
Any idea what's going on here? How can I get this Data Source to be recognized as having Change Tracking turned on, and why isn't it doing so when all is working as expected in our existing Search service with identical set up?
We will investigate. In the meantime, please try creating your datasource and indexer programmatically using the REST API or .NET SDK.
When I was experiencing this problem, I tried creating the search service via "Add Azure Search" in Azure portal > SQL database.
Using that wizard I was able to create the search data source, index & indexer.
Update: I opened a ticket with Azure support, and when trying to get more information to provide to them, I tried to reproduce the problem (create a data source via REST API), but the expected failure did not happen ("Change tracking not enabled for table..." despite it being enabled). This makes me think there was something wrong with internal Azure code that was fixed in the meantime.
I'm having a problem whenever I try to create a new Cosmos DB database through Azure Portal. I'm using a free subscription so I do not have access to CosmosDB support.
Basically, all values seem to be valid but after creation everything fails. I'm doing the following:
Input a unique ID with no spaces or uppercases or symbols.
Chose "Azure Table" as API type.
Use my "Free Trial" subscription.
Create a new resource group (again with no spaces or uppercases of symbols).
Choose a server in either "South UK" and "North Europe" (tried both on different tries).
Whenever I click finish, after some seconds, I get the following message:
Invalid capability EnableTable. ActivityId: ...
Microsoft.Azure.Documents.Common/1.10.106.1 (Code: BadRequest)
Error Message:
{ "code": "BadRequest", "message": "Invalid capability
EnableTable.\r\nActivityId: 9cb0e2eb-3b62-4bda-a0f9-e3945eb8148b,
Microsoft.Azure.Documents.Common/1.19.106.1" }
I also tried Edge and Chrome and neither work. I find funny that Microsoft says that we can try Azure's CosmosDB for free but in fact we can't because creation fails and they offer no support for free.
You need to use the below url and select the required service to try Cosmos DB free.
I just created one Cosmos SQL DB for free.
https://azure.microsoft.com/en-us/try/cosmosdb/
Problem Solved
Not really sure if this can be considered an answer, but my problem has solved itself somehow. Apparently the solution is to keep trying multiple times till it works.
If it helps the only different thing I did this time was:
Create first an Azure Cosmos MongoDB, including creating a new resource group
Create now the Azure Table DB using the existing resource group used by Mongo DB.
It worked.
Not sure if it was this or and Azure error or subscription issue, since I created my account today, so It could not be properly configured.