My azure search indexer which reads from an sql table with Change Tracking, is failing with the following error
"Unable to cast object of type 'Newtonsoft.Json.Linq.JObject' to type 'System.String'."
If I reset the indexer, it'll start working fine. What is the root cause of the problem here?
We’ve identified an issue in SQL indexers that use SQL integrated change detection that affects a very small number of customers. We’re working on a fix, which will probably be deployed in production next week. We'll also improve our telemetry so that we'll be able to identify this class of issues proactively.
The workaround you’ve already used (resetting the indexer) is the best workaround for this issue.
Sorry for the trouble!
Related
We have a release pipeline in Azure DevOps that deploys a database project to our Azure SQL Database via the Azure SQL Dacpac Task. Everything has been working fine but suddenly yesterday the pipeline started failing with the following error:
##[error]*** An error occurred during deployment plan generation. Deployment cannot continue.
##[error]Error SQL72018: Permission could not be imported but one or more of these objects exist in your source.
As far as I know, nothing has changed on the database side or in the pipeline. We also ruled out that it could be an issue with the specific dacpac file because previously successful releases now fail with the same error.
I searched extensively for the SQL72018 error, but didn't really find any answers as to what would be causing that so am wondering if there was some Azure DevOps task update or something that we could be missing?
Not sure what would have caused this to break out of nowhere like that.
It does work if we add the p:/ignorePermissions=true parameter to the task, but we have never needed that before this.
UPDATE:
Wanted to update this as I was able to gather a little more information by adding the /Diagnostics:True parameter to the pipeline task in order to print out Diagnostic info from SQLPackage.
When I added that, I also see this error:
Microsoft.Data.Tools.Diagnostics.Tracer Error: 1 : 2022-04-05T08:38:37 : Error detected when reverse engineering the database. Severity:'Warning' Prefix:'' Error Code:'0' Message:The permission 'VDP ' was not recognized and was not imported. If this problem persists, contact customer support.
So it looks like some "VDP" permission is what is causing the issue, but we don't know what that permission is for or where it came from as it's not in the database project.
We finally got to the bottom of this. It turns out a new permission was added to the database the day before the pipeline started to fail. The database permission that caused the issue was VIEW DATABASE PERFORMANCE STATE. That was the VDP permission that SQLPackage.exe was complaining about.
Unsure why that particular permission caused the error as we manage all of our database permissions outside of the database project, so not sure why other permissions wouldn't have caused issues prior to this one.
Since we are managing permissions outside of our database project, the resolution was to add the p:/ignorePermissions=true SQLPackage parameter to the pipeline permanently. This was confirmed as the appropriate solution by a Microsoft representative after we put a ticket in.
It seems you have a spurious/orphan permission in your target database - as mentioned in this post How could our database be causing SqlPackage to fail? (SQL72018).
I have been trying to set up a snowpipe to ingest data from blob storage in Azure into snowflake, following this guide, I think I have done everything correctly although I am new to azure and snowflake so may have missed something obvious. Everything seems to have been set up correctly on both sides, but whenever I check the pipe status using SELECT SYSTEM$PIPE_STATUS('azure_pipe');, I get the following:
{"executionState":"RUNNING","pendingFileCount":0,"notificationChannelName":"https://snowflakedata.queue.core.windows.net/snowflakequeue","numOutstandingMessagesOnChannel":2,"lastReceivedMessageTimestamp":"2022-02-18T13:25:12.107Z","channelErrorMessage":"downloadAttributes error:Queue not found for channel Name=https://snowflakedata2.queue.core.windows.net/snowflakequeue, AccountId=6713, NotificationChannelID=2045, IntegrationID=1784764","lastErrorRecordTimestamp":"2022-02-18T17:32:47.854Z"}
I'm not sure what I have done wrong, the snowflake app has the queue contributor role in azure and I'm fairly sure I set everything else up correctly. If anyone could point me in the right direction as to how to troubleshoot this that would be really helpful!
I had the same issue as you did just this week when trying to create a Snowpipe for Azure. Using SELECT SYSTEM$PIPE_STATUS('azure_pipe'); gave the exact same error message as you have shown above. Thankfully, Snowflake Support has provided me with the answer and an explanation.
Answer:
Drop all of the objects relating to the Snowpipe (integrations, pipe, stage, etc). Then recreate them in the exact order and specification as shown in this documentation.
Explanation:
The issue for me was caused because I kept using create or replace on the objects when I was modifying them (eg changing the comment on a pipe). This re-created the object and broke the links between the objects in the Snowpipe and prevented the Snowpipe from working as intended. Dropping and starting again solved it for me.
I've been working with Powerapps for about 3 to 4 months now, and this particular app I've created connects to 3 tables in an Azure SQL Server Database. It's been working great until today. This morning I logged in to edit a feature on the app and my galleries were empty with an error message saying: "Bad Data source Inner exception, Not a valid data Source".
My first thought was, something is off on the database, some planned work possibly during the night, but that's not the case, and the DB is working perfectly as I also use it in PowerBI.
I googled for the error and found several people with a similar issue, and most of them reported that deleting the Data Source connections from power apps and adding them again would fix the issue, as well as deleting and creating the Galleries again. I've performed both actions, and the same error returns. I tried creating a fresh new canvas app, with a gallery and a brand new connection to the Azure Sql DB and still got the same error. I've also tried to restore one of the oldest versions of the app, and I still got the same error. This to me all indicates there's a problem with the DB, but...when I publish the APP, and run the app after publishing, It works perfectly, and I have full usability of the app, which means the connection to the DB is actually working.
It feels like a bug to me. I'll share the screenshot of the error:
Error Message
I'm worried I will lose all my work, so if someone could help me, that would be great.
Finally, I got the solution for this issue. This are the steps I followed to solve the issue.
Remove all the Database connectors from your app.
Go to File -> Settings -> Advanced Settings -> Disable enhanced Microsoft SQL Server Connector.
Add all your Database connectors back again.
I have setup Azure search on my Kentico site. The search works fine.
When I try to setup automatic index build it fails.
So, it's never rebuilding the indexes. How can I fix this issues?
The error message suggests that either there are two columns with the same name or perhaps the case of a column name has changed somehow and Azure is struggling with that. I'd suggest dropping the index in the Azure portal and seeing if the automatic indexing will recreate it.
If you can go into the portal, it's worth checking the index definition to confirm that the fields are as you expect.
After installing a custom CLR object Sql Server Developer Tools (SSDT) VS2012 will not allow an update. The error is "Source schema drift detected. Press Compare to refresh. After refresh same thing happens.
Tried
In settings, I set the object to just Stored Procedures.
Settings ->General -> Block on possible data loss -> tried both on and off.
This sort of loop can also be caused by a referenced SSDT project failing to build. The referenced project may be missing, unloaded, or have an error which prevents the compare from completing.
This is not an answer but a clue to deal with this problem.
I was to update a colum from varchar[200] to varchar[MAX] and got this problem as well. So I logged in the server and tried to update the database manually via SQL Management Studio which was installed there, and I got this error:
"Saving changes is not permitted. The changes you have made require the folloing tables to be drpped and re-created. You have either made changes to a table that can't be re-created or enable the option Prevent saving changes that require the table to be re-created."
Seems that re-creating table is something so dangerous that "block/unblock on possible data lose" cannot handle. So I think only if we can walk around this LOCAL warning, could we update the database REMOTELY.
But, why [200] to [max] leads to re-creating table? It does not make any sense. I tried [200] to [1000], and it did not work as well. This might be the key to this problem.
And, if you do the same update in Server explorer in VS, instead of SQL Management Studio, it works. Again, why?
This can happen when a db user "changes".
The following rather scary forum page recounts issues where foreign hackers were trying to brute-force access to the "sa" db user, with each attempt changing the sa-user's date timestamp (which is seen as a schema drift):
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5c22a7b4-7a82-4717-a118-2475bc62705b/schema-compareupdate-error-target-schema-drift-detected?forum=ssdt
Here is also mentioned that you can query the sa-user a few times, to see if this is happening to you:
SELECT * FROM sys.server_principals WHERE principal_id=1
I am currently experiencing the same issue (that the sa-user is being modified; I know nothing about hackers yet) and am yet to find a solution.
Edit - I turned on logging in Windows Firewall via properties > logging, and we setup a blocking rule on port 3071, which had a lot of unexplained traffic. Then the problem went away.
I tried running VS as an administrator, it worked.