Jump to content
  • 3

Project Sharing Bugs


rb-arch

Question

Hello, I'm using VW 2017 architect in a 3 person office with a network.  We're doing our very best to keep using project sharing, but it is challenging.  When it works, it is great but....................... here are my issues which are on-going with all files:

 

  1. Updates not pushed to all users.  We'll edit, for example, a piece of millwork and the person who did the work see the changes and saves them.  The other two machines don't get the update no matter how long we wait.  Re-creating the project file solves this.
  2. Objects move.  Stuff gets shifted constantly, z direction of symbols change - all randomly.  Re-creating the project file solves this.
  3. Walls become unjoined.  This is irritating, and can sometimes be solved but again one user will see it and another will not.  Re-creating the project file solves this.
  4. Walls shoot off into space, again for some users.  Re-creating the project file solves this.

 

See the theme?  We're re-creating our project files daily.  This will lead to mistakes, and eventually to me issuing an incorrect set of documents.  What are we doing wrong?  We're working off local hard drives for the working files and the project file is stored on the server.  All users are administrative.  

 

The server is a new Mac Mini, and we're running all the latest apple software updates.  It should work better than this. 

  • Like 3
Link to comment

Recommended Posts

  • 0

@Tolu:

 

We use version 2017. You indeed are correct, the program doesn't prompt to check out the layers anymore. But this actually allows accidentally drawing an object on a layer and thus producing a "soft lock" unwittingly?

 

Even as it is, we don't check out individual objects any longer, only complete layers and we still get these issues.

 

Apparently there is no documentation about these "soft locks" in the VW help file, at least that I could find.

 

As rb-arch stated above, it is impossible to see these "soft locks" unless going through the layer list and seeing if the "release" button becomes enabled? Even then, one doesn't know which object is "soft locked" - if so, clearly something has to be done about this.

 

This also comes to the question that what if the owner of the "soft lock" and the admin are away from the office? Or in case these are the same person?

 

Perhaps there should be a separate option for releasing objects and layers that "project" users could also access, should the need arise, exluding other changes only admins can make.

 

 

 

 

 

Link to comment
  • 0
  • Vectorworks, Inc Employee
7 hours ago, JMR said:

Perhaps there should be a separate option for releasing objects and layers that "project" users could also access, should the need arise, exluding other changes only admins can make.

The Release (as an admin) provides this option. If an admin (or any user) knows he/she will be out, he/she must issue a "Close and Release" before leaving otherwise other users will be blocked.

 

If you want everyone to be Admin, Project Sharing will still work. You, however, must understand the consequences of releasing someone else's lock - lose of work.

 

If the work being done within the team overlaps (i.e. the objects/layers that I modify today will likely be used by another user tomorrow), then you might need a process in place. For example, you could require each member of the team to "Save and Commit" their changes (with auto release locks option turned on. This is an option on the Commit dialog) or "Close and Release" at the end of the day (or more frequently). In addition, each member of the team must use the same Working File, so that all locks are cleared once they commit (or close and release).  If you create a new WF and you check out an object/layer, that layer/object will remain checked out in that WF. Deleting the WF will not release the locks and "closing and releasing" in another WF will not release the lock in the first WF.

 

7 hours ago, JMR said:

Even as it is, we don't check out individual objects any longer, only complete layers and we still get these issues.

If this happens again, could you please send me your Project File? I would investigate the issue. 

 

Best Regards,

Tolu

Link to comment
  • 0

The process used is currently this:

 

-Users always use the same working file, named automatically as per user

-Users check out complete layers

-Users close and release at the end of the day / work session, at the least

 

-> these "soft lock" issues (if this is the case) still appear.

 

Thank you, I'll send you the project file the next time we get these errors. I guess I must send the working files as well since re-creating the working files from the project file always removes these issues.

 

Enclosed are some screenshots of unexplained errors we get:

 

-"Opening and refreshing working file may... " : This is a "false" error - no changes exist in the project file and no data is lost if the working file is opened. This occurs quite frequently, despite hassle-free save/close and release previously.

 

-"The attempted operation cannot be completed..." : Here I'm trying to open my own file. VW says I've checked out objects, even though I have not.

 

-A screenshot of the project sharing window: Here I went through all layers individually to see if the release button would become enabled, but it didn't. I guess the last user shown working on something completely unrelated somehow had a lock on something.

 

 

 

 

Project sharing -changes exit...JPG

Project sharing error.JPG

Project sharing -no release button enabled.JPG

Link to comment
  • 0
  • Vectorworks, Inc Employee
51 minutes ago, JMR said:

-Users always use the same working file, named automatically as per user

-Users check out complete layers

-Users close and release at the end of the day / work session, at the least

 

-> these "soft lock" issues (if this is the case) still appear.

If that's your workflow then soft locks plays no part. Soft locks are only created when you are using object-level check out. 

 

52 minutes ago, JMR said:

Thank you, I'll send you the project file the next time we get these errors. I guess I must send the working files as well since re-creating the working files from the project file always removes these issues.

Working Files will be helpful as well. Thanks.

 

54 minutes ago, JMR said:

-"Opening and refreshing working file may... " : This is a "false" error - no changes exist in the project file and no data is lost if the working file is opened. This occurs quite frequently, despite hassle-free save/close and release previously.

This alert is triggered when Vectorworks detects that your Working File data is out of date (i.e. the data in the WF no longer correlates with the PF). This often happens when using a WF backup but it is also possible if Vectorworks crashed after commit but before WF was saved. Are you experiencing frequent Vectorworks crashes during "Save and Commit"?  

 

54 minutes ago, JMR said:

-"The attempted operation cannot be completed..." : Here I'm trying to open my own file. VW says I've checked out objects, even though I have not.

If you are still seeing this, could you please send me your PF and WF? I can determine what's causing the alert.

 

55 minutes ago, JMR said:

-A screenshot of the project sharing window: Here I went through all layers individually to see if the release button would become enabled, but it didn't. I guess the last user shown working on something completely unrelated somehow had a lock on something.

Are you using Vectorworks 2017 SP4?

What happens if you select only the "_Pohjapiirustus 1 .krs. alapohja" layer only?

 

Best Regards,

Tolu

Link to comment
  • 0
  • Vectorworks, Inc Employee
19 hours ago, rb-arch said:

IMO these soft locks might be the root of some of these problems.  

 

There are *many* times when we do our work, save / commit /  release only to find out later that there is still an obect checked out by another user.

I would recommend a workflow where each user use one single WF. This will simplify the management of WFs and it will eliminate the problem where objects are locked in other WFs. 

Note that if you work, save / commit /  release, this will only release object is the active WFs. If you have other WFs they are not affected.

 

Thanks,

Tolu 

Link to comment
  • 0
On 7.9.2017 at 7:36 PM, Tolu said:

If that's your workflow then soft locks plays no part. Soft locks are only created when you are using object-level check out. 

 

Working Files will be helpful as well. Thanks.

 

This alert is triggered when Vectorworks detects that your Working File data is out of date (i.e. the data in the WF no longer correlates with the PF). This often happens when using a WF backup but it is also possible if Vectorworks crashed after commit but before WF was saved. Are you experiencing frequent Vectorworks crashes during "Save and Commit"?  

 

If you are still seeing this, could you please send me your PF and WF? I can determine what's causing the alert.

 

Are you using Vectorworks 2017 SP4?

What happens if you select only the "_Pohjapiirustus 1 .krs. alapohja" layer only?

 

Best Regards,

Tolu

Tolu,

 

I sent you a message with a sharepoint download link to our problematic files.

 

We do experience a bit too many crashes when committing. I've noticed committing often enough helps with this, once a day is too seldom and may cause crashes.

 

We run SP4.

 

Selecting "_Pohjapiirustus 1 .krs. alapohja" layer didn't enable the release button, however we were able to solve the issue by saving the project into a VWX file and then re-sharing it.

 

It would seem that sometimes the soft locks remain in force, even though the daily work has been saved and committed/released.

 

Now that I know to look for that enabled "release"-button, that has helped very much with these issues.

 

Thanks

 

Link to comment
  • 0

We're still experiencing significant problems with project sharing, especially point #1 in the OP.

 

Quite frankly, we're sick of being the beta testers for this software.  I'd prefer an issue of the software that improved the core commands over improvements to the site model for example.  Of course all improvements are welcome but I get the sense that the focus is on new shiny stuff rather than the core of the software.  Not good.  

 

Project Sharing is critical, and if this continues much longer we'll be faced with a difficult decision.  

  • Like 1
Link to comment
  • 0

@Tolu:

 

I've been tracking the soft locking issues while we work. Here's what I've found:

 

  1. The soft locks frequently happen, accidentally.
  2. The program doesn't warn about these soft locks occurring.
  3. There is no way to spot the soft locks, other than going through the project sharing window and check if the "release" button becomes highlighted.
  4. The program does not always indicate the soft locks through the "release" button becoming highlighted, even when there are some!
  5. Perhaps most importantly, selecting "release" for the particular layer in the project sharing window does not always release the soft locks.'
  6. The only way to release the soft locks reliably is to use the "Close and release" option in the file menu.

 

As conclusion, it would seem the soft lock release mechanism isn't perfect.

 

Additionally, there should be a clear indicator when a soft lock occurs, and the right-click "release" option should release these soft locks as well.

 

Since starting to use the "close and release" option to handle the persistent soft locks, we've been able to work better. However, still too many crashes.

 

Thanks

 

 

 

  • Like 1
Link to comment
  • 0

I've been posting left right and centre about project file sharing issues at the moment, as we've been having massive problems with them. On top of all the issues mentioned above, there is some strange behaviour in terms of '...Project File is in use by another user...' coming up frequently.

 

This is to be expected from time to time, but the issues we are having:

 

- '...Project File is in use by another user...' when no other users are on the file

- When an entire layer is checked out, the WF doesn't need to communicate with the project file for the most part, so at least we can get on with some work without '...Project File is in use by another user...' coming up a few times with practically every change.

- However, even when the entire layer is checked out, certain operations seem to still cause the WF to communicate with the PF, such as:

      - When editing a group

      - When changing the stacking order of any item

      - When editing a polygon

 

Any idea why this is the case? Should this be the case?

  • Like 1
Link to comment
  • 0
  • Vectorworks, Inc Employee

@Asemblance

Are you seeing this problems in both Vectorworks 2017 SP4 and Vectorworks 2018 SP1?

 

4 hours ago, Asemblance said:

- However, even when the entire layer is checked out, certain operations seem to still cause the WF to communicate with the PF, such as:

      - When editing a group

      - When changing the stacking order of any item

      - When editing a polygon

I just tried this on my side and no communication was attempt with the PF. How are you noticing the communication with the PF?

 

I see your specs as using OS X 10.11.6, are you also using a Mac OS Server?

 

Thanks,

Tolu

Link to comment
  • 0
4 hours ago, Asemblance said:

I've been posting left right and centre about project file sharing issues at the moment, as we've been having massive problems with them. On top of all the issues mentioned above, there is some strange behaviour in terms of '...Project File is in use by another user...' coming up frequently.

 

This is to be expected from time to time, but the issues we are having:

 

- '...Project File is in use by another user...' when no other users are on the file

- When an entire layer is checked out, the WF doesn't need to communicate with the project file for the most part, so at least we can get on with some work without '...Project File is in use by another user...' coming up a few times with practically every change.

- However, even when the entire layer is checked out, certain operations seem to still cause the WF to communicate with the PF, such as:

      - When editing a group

      - When changing the stacking order of any item

      - When editing a polygon

 

Any idea why this is the case? Should this be the case?

 

We have been experiencing the exact same issues on VW 2018 SP1 and as such have abandoned Project Sharing all together. Too much time is wasted loosing 'un-commitable' work and rebuilding Project Sharing files. 

 

Very much hoping these issues are addressed in SP2.

Edited by mthompson
Link to comment
  • 0
On 11/2/2017 at 7:01 PM, Tolu said:

Are you seeing this problems in both Vectorworks 2017 SP4 and Vectorworks 2018 SP1?

 

I just tried this on my side and no communication was attempt with the PF. How are you noticing the communication with the PF?

 

I see your specs as using OS X 10.11.6, are you also using a Mac OS Server?

 

Thanks,

Tolu

 

Hi @Tolu

 

I've been able to find at least one of these instances which is easily replicated, which involves 'trimming' polygons (where both the object used to trim, and the object being trimmed, are both on a 'checked out' later).

 

Recorded a quick screen grab - it also shows the 'project sharing file is in use' problem we get a lot (there was nobody else using the file at the time).

 

 

I'm not sure of the details of our server, I'll find out a little more info.

 

 

 

Link to comment
  • 0
  • Vectorworks, Inc Employee

@Asemblance

Thanks for taking the time to do a screen recording. I was able to reproduce the clipping problem. We will fix this for SP2.

 

After watching your video, I strongly advice that you check your Server and Network configurations. Your server (or network) is extremely slow in responding to object/layer check outs. Checking out a layer should be much faster. You shouldn't see the progress bar at all. Vectorworks is spending too much time waiting for your server to respond.  

 

5 hours ago, Asemblance said:

it also shows the 'project sharing file is in use' problem we get a lot (there was nobody else using the file at the time).

Again, I think this is attributed to serious hardware problems - Server or Network configurations issues. Vectorworks tries a number of times to communicate with the PF and if that communication fails or the    communication times out, you will get that message. 

 

Best Regards,

Tolu

Link to comment
  • 0
20 hours ago, Tolu said:

@Asemblance

 

...After watching your video, I strongly advice that you check your Server and Network configurations. Your server (or network) is extremely slow in responding to object/layer check outs. Checking out a layer should be much faster. You shouldn't see the progress bar at all. Vectorworks is spending too much time waiting for your server to respond.

 

 

Again, I think this is attributed to serious hardware problems - Server or Network configurations issues. Vectorworks tries a number of times to communicate with the PF and if that communication fails or the    communication times out, you will get that message.

 

Thanks for the Response Tolu.

 

I'm glad to hear the bug will be picked up in SP2, thanks! I have also discovered the same issue occurs when moving items forwards or backwards, but again only when dealing with polygons. I imagine this problem is linked in some way to the 'trim' problem highlighted in my video above.

 

It is interesting to get your perspective on the speed problems with the file/our network. I don't know much about our setup, but can confirm that it is a NAS setup with some sort of RAID configuration. Whilst not 100% rock solid (we get occasional issues with it), in most instances it is very fast and responsive - when not dealing with project sharing files, saves to files stored on the server are completed almost instantaneously, or in 1-2 seconds.

 

So I find it unlikely that this issue is purely down to communication speed with our server.. it seems likely there is something in particular about Project Sharing Files which is causing difficulty.

 

I notice @JMRalso mentioned a NAS setup with RAID above, most likely the same issue.

Link to comment
  • 0

Did I get that right ?

 

- all PS problems only appearing on Mac while PCs are fine ?

- all PS problems just related to network problems ?

- AFP is officially legacy by Apple but will work ok in a Mac-only environment ?

- AFP/SMB combined networks for Mac+PC Networks can be set but will never work :)

- Apples Network recommendation is to use Apples SMB but Apple SMB is buggy ?

Link to comment
  • 0
  • Vectorworks, Inc Employee

I have an update from engineering. This is not related directly to the original post of this thread, but has come up internally because of other replies:

We currently have a working theory about performance problems with Project Sharing that relates directly to NAS devices with a RAID configuration (So, any NAS setup thats housing multiple disks most likely will be configured this way.) and we are acquiring hardware to test this now. This type of configuration was not initially checked with Project Sharing (we previously used dedicated servers and single drive NAS devices in our tests) and so, is currently unsupported until we can verify any existing or possible issues. ANY users currently encountering problems with Project Sharing that have a multi disk NAS device being used in any way as part of their PS workflow, please reply back to this thread with the make and model of the NAS you are using along with any symptoms related to it you have encountered if you have not already posted them. Thank you.

If your workflow does not involve a NAS device with a RAID array inside would be unaffected by this testing. 

Link to comment
  • 0

Thanks for the update,

 

Our NAS systems are (and were) as follows (exact same issues on both systems)

 

Old: 

100Gbit Ethernet / Lacie Network Space Max 2.0 running RAID 1 configuration, 2 disks

 

New:

1000Gbit Ethernet/ Synology DS1517+  running RAID 6 configarion, 5 disks

 

Please note that we have not encountered any performance issues when it comes to speed, only reliability issues (please see above thread). File I/O is very fast as such.

 

 

 

 

Link to comment
  • 0

After countless back channel discussions, we still have the following (serious) problems with SP2.  We have already issued drawings to the site that were in error because of project sharing, and I see no fixes to date for the following:

  1. Sheet layer work (when a user has the ENTIRE project checked out) is not pushed to the PF and other WF in the office.  This happens regularly, and we try to ask "what were you working on", but things fall through the cracks.  How do you summarize 3-4 hours of work to a co-worker - you can't.   We have a situation right now were sheet re-ordering, viewport organization, and sheet re-naming is stuck in one machine.  Nothing will push the work through.  We have to remake the project file.
  2. Same as above for solid modelling in design layers.  In that case sometimes we group the entire design layer and save and commit, and it will push the work through.  
  3. Walls become unjoined, randomly, and frequently.
  4. Legend text, which resides in a design layer, will set itself to zero point font.  That makes it disappear from the sheet layers.  We had 5 sets of drawings issued to site with this error, which only occurs with project sharing.  

So, we'll continue to beta test his for Vectorworks, on our dime.  Note, we've taken every bit of advice from all parties for network settings, autosave settings, etc.  Our network is new and fast, and our workflow is not exotic.  

 

randy 

Link to comment
  • 0

Hi All,

 

I just wanted to jump in on this conversation because our 4-person office is also getting used to Project Sharing. I come from a Revit background so I'm used to project sharing but it doesn't seem to work quite as well in Vectorworks. This is our first project where we are using project sharing. I am the model administrator and when I set up the file I set the network protocol to AFP since we are using a Mac operating system and a Mac mini server. On day one this worked smoothly... everyone was able to create their own working files, work on the model, save and commit changes, and refresh to see all the changes that had been made. The next day when we opened our local files (stored on our local harddrives, not on the server), we all received the attached error notification when we tried to save and commit. I decided to remedy this by going into the project share settings and change the network protocol to SMB. I saved and committed and everyone hit refresh. The changes worked for me but not for anyone else. So I am the only one who can now save and commit to the project file on the server. When my coworker checked his document settings, the SMB network protocol setting was selected but he still receives this error message...

 

Has anyone else run into this issue? I am hoping there is a relatively simply solution.

 

Thanks,

Deborah

ATT00001.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...