Activity overview
Latest activity by devrok
Alex B said:
Hi @devrok, You are very welcome! I thought of one thing you could do - you could have a "pre-deploy" copy of each customer database where you deploy the metadata and create the deployment scripts with the migrations and metadata and then write a script to remove the metadata when you deliver it to the customer. This would let your pre-deploy database keep track of the metadata and allow accurate creation of deployment scripts and then also allow you to only provide the meta-data free deployment script. You would just need to ensure that your pre-deploy environment was in exactly the same state as the customer database (but would also maintain the metadata tables). I hope that helps! Kind regards, Alex
Hi again! Thank you for your efforts, I did not expect that :-) It was planned to replace our existing self created scripting tool to reduce maintenance time and use these resources for other necessary things. Therefore it seems that we will stick to our existing solution but the decision will be made by my manager ;-) But great job, you are very friendly and competent. Kind regards, devrok / comments
Alex B said:
Hi @devrok,You are very welcome!I thought of one thing you could do - you could have a "pre-deploy" copy of each customer database where you deploy the metadata and create the de...
Alex B said:
Hi @devrok, The DeploymentMetadata is necessary when using the migration scripts. This is what lets the product know what migrations have been run so that if you deploy to this target again, it does not attempt to redeploy the migrations it already has deployed - see this page for more information. If you want these to be removed you will need to use the "Ignore migration scripts for databases" option so that the migrations are not deployed and therefore the DeploymentMetadata is not needed. Kind regards, Alex
Hi Alex! Thank you for the quick response. It sounds pretty logic that this metadata is necessary for executing the scripts in correct order and only for one time. The plan was to use SQL Compare combined with SQL Source Control to create schema and migration scripts automatically and ready to deploy to the customer without any additional data. Although I'm not sure if we can use your tools as they are, I want to thank you again. Have a nice day!! [image] devrok / comments
Alex B said:
Hi @devrok,The DeploymentMetadata is necessary when using the migration scripts. This is what lets the product know what migrations have been run so that if you deploy to this t...
Alex B said:
Hi @devrok, The DeploymentMetadata is necessary when using the migration scripts. This is what lets the product know what migrations have been run so that if you deploy to this target again, it does not attempt to redeploy the migrations it already has deployed - see this page for more information. If you want these to be removed you will need to use the "Ignore migration scripts for databases" option so that the migrations are not deployed and therefore the DeploymentMetadata is not needed. Kind regards, Alex
Hi Alex! Thank you for the quick response. It sounds pretty logic that this metadata is necessary for executing the scripts in correct order and only for one time. The plan was to use SQL Compare combined with SQL Source Control to create schema and migration scripts automatically and ready to deploy to the customer without any additional data. Although I'm not sure if we can use your tools as they are, I want to thank you again. Have a nice day!! [image] devrok / comments
Alex B said:
Hi @devrok,The DeploymentMetadata is necessary when using the migration scripts. This is what lets the product know what migrations have been run so that if you deploy to this t...