Moving Database Tables to different project

[AkshayKhanolkar]

Steps to recreate the issue:
1. Create a Task and a project associated with the task.
2. Use add existing and checkout an existing database table in that project.
3. Make the required changes to the database table. (Add new columns or edit existing ones)
4. Create a new task and a new project.
5. Move the checked-out database table into the new project.
6. Promote the database table through the new project into QA.
In this situation, the old project retains the ALTER DATABASE information and does not pass it on to the new project.
So the project gets promoted without the alter database prompt and the tables in QA do not get updated.
If you redo the changes in the new project this will also create a deadlock because that will have a DROP on the columns which do not exist in QA.
eg.

Code: Select all

Error Promoting: Error in query. Query:USE EP_Platform_QA
ALTER TABLE EASYItem_Data.Item_Requests_Bulk
ALTER COLUMN AdditionalBPRequirements varchar(1023) ;-- where. Error: ALTER TABLE ALTER COLUMN failed because column 'AdditionalBPRequirements' does not exist in table 'Item_Requests_Bulk'.
Changed database context to 'EP_Platform_QA'. See inner exception for stack trace.

If you undo checkout and import the sources back into the old project, the old project still retains the ALTER information from the prev changes.
The only fix at this point is to delete all the new changes manually from the database tables and start over again.

[AkshayKhanolkar]

Matt M raised this issue on the Slack channel as well. Here is his short description of the issue:
"If you move a DB Table change from one project to another and then promote to QA, it does not move the DB table change. I had to demote it, move it back to the original project, then promote that to QA."

[CathyC]

We saw issues with this working with Safa where 8 projects had become dependent and we wanted to move all the sources to one project and make that one project have the 8 tasks instead (so future developers would be aware of the dependency). This bug prevents us from doing that.