Best practice for deploying projects subsequent to making table changes

I would be tempted to clean up the project as you suggested. The other thing that I would likely do would be to keep my original project with the custom table up to date and put the SQL scripts into a separate project so I can run it once and then delete it.

@Django FANTASTIC idea.  Thank you!

@Joe Schmucker If I were to manage this kind projects that requires DB Objects manipulations. I would add a table with only one int column to keep the package version. At the beginning of running my DB Scripts I would always get the value from DB for this field and execute my block of code if the criteria would match other wise I wouldn’t and at the end of my customization package I would always update this hidden table single column with my latest version number. This way because that table always keeps a single record that represents the latest published version, and you check that value in scripts, then older scripts won’t be executed. You can have everything in one package as well.

@aaghaei That’s sounds like a great idea.  Would all of this be done within the SQL script itself?

@Joe Schmucker yes

@Joe Schmucker if you need help with that we can have a quick Teams call

@aaghaei I’m fairly savvy with SQL.  I think I can do what you suggested.  I didn’t know if there was some kind of functionality in the publish process such as a “pre publish” function.  When the project is being published, there are all kinds of “actions” occurring and I thought maybe there was some way to add my own custom “action” into that process.  If it is just being done in SQL, I think I got that part ok.

Thanks so much for the suggestion.  

@Joe Schmucker Great,

I am sure you know how to add SQL Scripts to the Customization Projects. So the SQL script in question will live inside your Customization Package.