Forum Discussion
Importing bacpac to Azure database fails
Thanks!
I tried creating the bacpac file using ssms instead of sqlpackage and suddenly it worked. So, any ideas as to why the bacpac file created by ssms works better than the one created by sqlpackage? Do I need to add some argument or parameter to make sure that the export is compatible with azure sql server? I really want to use sqlpackage since i want to be able to script the entire process.
The difference you're experiencing between SSMS and SQLPackage when creating the .bacpac file is likely due to differences in how the tools handle the export process. SSMS has some built-in mechanisms that might better handle certain data integrity checks or constraints compared to sqlpackage
SSMS tends to be more forgiving with data consistency and has built-in safeguards to handle data dependencies and constraints more smoothly, especially for data being exported directly from a production environment.
SQLPackage, on the other hand, is a more direct, scriptable method and might not have the same inbuilt adjustments unless explicitly specified.
To get a similar level of reliability with SQLPackage, you can use specific parameters to ensure compatibility and avoid issues like primary key violations or other data integrity errors:
Common Parameters to Use:
/p :
During export, it might be beneficial to ignore certain constraints temporarily and reapply them once the data is imported successfully.
/p:IgnoreConstraints=true
/p :
This ensures that differences in versions (e.g., SQL Server 2022 vs. Azure SQL Database) are managed more smoothly.
/p:AllowIncompatiblePlatform=true
/p =False:
If your database contains Full-Text Indexes, this can sometimes cause issues. Disabling this verification can prevent those errors.
/p:VerifyFullTextDocumentCount=false
/p :
Ensure that database options are scripted during the export to make it compatible with the Azure environment.
/p:ScriptDatabaseOptions=true
/p :
If the process is timing out during export or import, increase the command timeout.
/p:CommandTimeout=1200
The size of your database could also play a role. The SSMS interface might handle chunked data export and reconnections better compared to a command-line approach.
Ideally, restore a copy of the production database to a staging environment. This ensures no active modifications are happening during the export.
Run sqlpackage with the parameters mentioned above to ensure better compatibility:
sqlpackage.exe /Action:Export /SourceServerName:<YourServerName> /SourceDatabaseName:<YourDatabaseName> /TargetFile:<YourTargetFile.bacpac> /p:IgnoreConstraints=true /p:AllowIncompatiblePlatform=true /p:VerifyFullTextDocumentCount=false /p:ScriptDatabaseOptions=true /p:CommandTimeout=1200
- mans_tannerydNov 09, 2024Copper Contributor
The properties you mention above do not work for the export action. It seems to me that they are only available with the publish action.
- mans_tannerydNov 08, 2024Copper Contributor
Thanks! I'll try that.
What bugs me is that there really are no duplicate keys (I know this for a fact) so the error message sort of sends me on a wild goose chase.