File sharing problems when user overrides their working file without committing

[ekeshet]

Has anyone had a problem where the team gets locked out of editing objects / layers because someone apparently has ownership of the item, even when they have committed and are no longer in the file?

 

I believe it stems from when the exit their working file without committing (or more likely, it crashed) and then they begin a new file by clicking on the Masterfile, which saves-over their working file.

 

This is driving our team crazy, and we are not loving being the beta-testers for VW worksharing. This is killing our office to the point we are seriously talking about moving into REVIT.

[PVA - Admin]

Which version of Vectorworks is this, what service pack, and on what operating system?

[ekeshet]

This is Vectorworks 2017, Build 333939, latest service pack on El Capitan.

 

I resolved this by telling my team to commit and leave their files.

 

I then refreshed and made a "saved as a copy" of my working file as a .vxw

 

I deleted the masterfile on the network (desperate times call for desperate measures) , and replaced it with my .vxw file.

 

I think opened that file and made it a .vxwp.

 

This resolved all of the ownership issues of items, and incidentally made all of our working files operate much faster.

 

In then end, I isolated the original problem down to one user having multiple "working file id"s.  Some of the file id's could not be recovered on their individual computers, because they had been saved-over. These "ghost ids" were still had checked-out items, and were really paralyzing the model. 

 

I'm not sure if the ghost ids had anything to do with the extreme slowness of our working files. Maybe the Project File just needed some sort of de-frag operation.