You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use azure sql tuning advisor to apply indexes it sees as beneficial. As such our db structure in our solution isn't always in sync with what's in the target schema.
We attempted to use the "DropIndexesNotInSource" argument set to false to prevent the azure generated indexes from being dropped before we have a time to analyze them and internalize them into our solution.
Based on the documentation we've found, it does not seem like indexes is an accepted value for passing to the "DoNotDropObjectTypes" argument.
Arg list /Action:Publish ` /SourceFile:$dacpacPath ` /TargetConnectionString:$connString ` /V:Configuration=$publishConfig ` /p:BlockOnPossibleDataLoss=false ` /p:NoAlterStatementsToChangeCLRTypes=true ` /p:DeployDatabaseInSingleUserMode=false ` /p:IncludeTransactionalScripts=$includeTransactionalScripts` /p:CreateNewDatabase=false ` /p:BackupDatabaseBeforeChanges=false ` /p:DropObjectsNotInSource=true ` /P:DropIndexesNotInSource=false ` /p:ScriptDatabaseCompatibility=true ` /p:ScriptDatabaseOptions=true ` /p:IgnoreFileAndLogFilePath=true ` /p:IgnoreFillFactor=true ` /p:IgnoreUserSettingsObjects=true ` /p:AllowIncompatiblePlatform=true ` /p:DoNotDropObjectTypes=$objectTypesToKeep ` /p:IgnoreColumnOrder=true ` /p:CommandTimeout=1200
But what we end up seeing is the indexes being dropped anyway:
@ErikEJ It might, but then it would be nice if indexes were an allowed value in the do not drop object types argument. Those seem to play nice together.
We use azure sql tuning advisor to apply indexes it sees as beneficial. As such our db structure in our solution isn't always in sync with what's in the target schema.
We attempted to use the "DropIndexesNotInSource" argument set to false to prevent the azure generated indexes from being dropped before we have a time to analyze them and internalize them into our solution.
Based on the documentation we've found, it does not seem like indexes is an accepted value for passing to the "DoNotDropObjectTypes" argument.
Arg list
/Action:Publish `
/SourceFile:$dacpacPath `
/TargetConnectionString:$connString `
/V:Configuration=$publishConfig `
/p:BlockOnPossibleDataLoss=false `
/p:NoAlterStatementsToChangeCLRTypes=true `
/p:DeployDatabaseInSingleUserMode=false `
/p:IncludeTransactionalScripts=$includeTransactionalScripts`
/p:CreateNewDatabase=false `
/p:BackupDatabaseBeforeChanges=false `
/p:DropObjectsNotInSource=true `
/P:DropIndexesNotInSource=false `
/p:ScriptDatabaseCompatibility=true `
/p:ScriptDatabaseOptions=true `
/p:IgnoreFileAndLogFilePath=true `
/p:IgnoreFillFactor=true `
/p:IgnoreUserSettingsObjects=true `
/p:AllowIncompatiblePlatform=true `
/p:DoNotDropObjectTypes=$objectTypesToKeep `
/p:IgnoreColumnOrder=true `
/p:CommandTimeout=1200
But what we end up seeing is the indexes being dropped anyway:
The text was updated successfully, but these errors were encountered: