DacFx
DacFx copied to clipboard
Getting log message "object [data_0] and [log] exists in the target, but it will not be dropped" in SQL release pipeline
- SqlPackage or DacFx Version:
- .NET Framework (Windows-only) or .NET Core:
- Environment (local platform and source/target platforms):
Steps to Reproduce: I m getting this two log message in my azure SQL release pipeline which internally using sqlpackage.exe to publish the dacpac.
***The object [data_0] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box.
*** The object [log] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box.
I don't no the reason why I m getting this log message, I m using azure SQL database.
(DacFx/SqlPackage/SSMS/Azure Data Studio)
What version of SQL Server was the dacpac created from? Is it also Azure SQL db or is it on-prem?
What version of SQL Server was the dacpac created from? Is it also Azure SQL db or is it on-prem?
@kisantia its a azure SQL db
Please share the .dacpac (privately) - the error indicates a non Azure SQL target
Hi,
I'm getting the same error.
Same issue for me when trying to deploy my dacpac file to the Azure SQL Database. Not sure about what specific objects this refers to.
Let me know if you need any specific details for investigating!
@zijchen @llali fyi a few people have been running into this. Could one of you please help?
there are certain objects (e.g FileGroup) which cannot get deleted in the target database. If you have a project trying to publish to a database with file group but the file group doesn't exist in the project you will get that error. These are just warnings and can be ignored in the build
Can you share the diagnostics log file from sqlpackage? If you could share a dacpac/simple repro that would be even better.
To further investigate this issue, we need at a minimum the diagnostic log (/df parameter) from a deployment.