Multiple Developers - Versioning & Locking

We face the same issue. Any updates on when it will get resolved?

Would be great if developers would get a more visual notification of a table has been 'locked’ by an other developer.

Even better would be a definite lock on a table like a check in out / check out system where other developers can't make changes to the table, because it has been checked out / there is a work item on that table.

Did you test Work Items?

Hard-locking items would lead to other issues (like you had with CVS version control back in the day). In the new release it is easier to divide-and-conquer the platform as each instance has its own repository, you also don't have to ship backups to TimeXtender as they are already hosted there.

In the end, the key is to assign responsibilities in a way that minimizes overlap. This reduces the contested parts of an implementation and makes it much easier to develop a ‘gut-feel’ among developers.

Having more control over how hands-on / hands-off you want the Work Items system to be would be very useful. As would be more visual cues on items that currently do not show whether they have been touched by any changes.

Yes we do use the working items, but once in while it still happens that two developers are working in the same table. Especially when the development team is big. And due to the fact that partial / continuous release is not possible these issue might become more pressing.

In retropect I have to agree with Rory. A more control, checks or notifications would be great and very helpful

I’m agree with you Daniel, this mornig I get an error related to this:

And now I’m not be able to open the instance that was change by another developer yesterday.

I’ve send a support tickek and I’m waiting the solution.

I could open one of the previous versions but I will lost one complete day of work.

Hi rvgfox,

as the error tells you the table with a uniqueness issue you can actually try to help yourself: The error is saying the unique constraint on that table is being broken (I think). Open the affected repository in SSMS and query the table mentioned. Something like:

SELECT 
      [ProjectId]
      ,[SourceDataFieldId]
      ,[DestinationDataFieldId]
      ,[ValidTo]
      ,COUNT(*) AS [CNT]
  FROM [projectRepository].[dbo].[DataMovementRelations]
  WHERE ValidTo = 99999999
  GROUP BY 
  [ProjectId] ,
    [SourceDataFieldId] ,
    [DestinationDataFieldId] ,
    [ValidTo] 
  ORDER BY COUNT(*) DESC

I would expect there to be at least one item with CNT > 1. This would be the problem, removing the offending records will allow you to load the project. If you are not comfortable with changing the repository, I would allow TimeXtender to resolve it for you.

It is possible that these kind of errors do not list a table, then you either need to know what was changed or supply TimeXtender with a .bacpac of your repository so they can fix it.

Thanks Roy but with the new version, the repository it’s in the cloud 😭

Ah, this is true - at least you don't need to ship .bacpacs then 😀

Hey rvgfox,

It’s true the repository is on TX Azure hence in the cloud. I’ve had the discussion with a few end customers and since the security setup is designed in the way it is and the fact that no actual data (just the meta data) is stored in the cloud repository these customer have gone for the new version, despite being on-prem as strategy. The fact that TX manages the repository over time automatically also weigh in as making it both secure and good practice.