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

We have issues with project sharing, too.

We get unexplained error messages and warnings. Today I encountered objects duplicating and shifting for the first time.

There is also some bizarre, unexplained behavior like resource browser folders acting strange, visible to some but not visible to some.

One of our team isn't able to have a totally unrelated VW file open while working on the project working file.

 

The working files and the project files are on a fast network drive with no connection issues.

Saving and committing and then removing the working file and creating a new one from the project file usually helps with these issues.

 

I would like to know, is someone using project sharing successfully, without these bizarre issues?

Link to comment
  • 0

Just to confirm when you say recreating the Project File you mean the one residing on the server?

So periodically taking a working file, saving as a standard file, then pulling it back to being a working file again?

 

We have been using 2016 Project sharing and noticed a few of these issues. Generally getting 2-3 weeks of development before hitting a problem. 

 

Link to comment
  • 0

All files reside on a server, which is simply a dedicated network drive.

 

There seems to be two ways to "solve" these issues:

-saving and committing, then deleting the working file and reopening the project file and thus re-creating the working file

-if it is a really serious issue, saving the project temporarily as an ordinary .vwx file and then re-sharing it.

 

I'm glad to hear project sharing works better for you.

 

We had to get a new network since the previous one was getting old, but the behavior remains the same.

 

We're in a PC environment, maybe it has something do to with this.

Link to comment
  • 0
17 hours ago, Matt Overton said:

Just to confirm when you say recreating the Project File you mean the one residing on the server?

So periodically taking a working file, saving as a standard file, then pulling it back to being a working file again?

 

We have been using 2016 Project sharing and noticed a few of these issues. Generally getting 2-3 weeks of development before hitting a problem. 

 

Yes.  We take the person with the best / most updated working file and flatten it to a .vwx file then re-create the project file on the server.

Link to comment
  • 0
12 hours ago, JMR said:

All files reside on a server, which is simply a dedicated network drive.

 

There seems to be two ways to "solve" these issues:

-saving and committing, then deleting the working file and reopening the project file and thus re-creating the working file

-if it is a really serious issue, saving the project temporarily as an ordinary .vwx file and then re-sharing it.

 

I'm glad to hear project sharing works better for you.

 

We had to get a new network since the previous one was getting old, but the behavior remains the same.

 

We're in a PC environment, maybe it has something do to with this.

We were advised to keep working files on the local drives, and save / commit back to the server.  Working files on the network doesn't make sense to me as the point seems to be to lessen network traffic.  I feel that the project files are not working property in pushing the updates to the working files, and when they do there is corruption along the way.  So far we've not had any fixes to the list I made in the OP.

Link to comment
  • 0

Interesting. Did this advice come from VW technical support?

 

I'd like to keep working files on the server since the serves is backed up constantly, and the individual pc's are not.

 

The network connection is linked 2x1Gbit connection and opening and writings files is very quick currently.

 

 

Link to comment
  • 0

I do no project sharing (with myself)

But I would always keep working files locally.

(less traffic, more speed, ...)

 

I use normal VW backup copies every 8 minutes or so.

(And on Mac you have additional time machine backups)

If you lose data on a local machine, you will have other serious problems,

beside a lost working file, anyway.

 

So I don't see backups as a reason to not store working files locally.

Edited by zoomer
Link to comment
  • 0
6 hours ago, JMR said:

Interesting. Did this advice come from VW technical support?

 

I'd like to keep working files on the server since the serves is backed up constantly, and the individual pc's are not.

 

The network connection is linked 2x1Gbit connection and opening and writings files is very quick currently.

 

 

 

It came from the software dealer, who is my point of contact for support (they're pretty good).  We also back up our local drives with time machine usb drives so we're covered that way.  Their advice, conceptually, made sense to me.

 

Yesterday we had a project double all the section line instances, making double view ports on 12 sections.  

Link to comment
  • 0

To sum it up, if I understand correctly:

 

-Having working files on local drives might be beneficial to network speed, but does not prevent the occurrence of project sharing problems

-Seems project sharing is not ready for professional deployment?

 

The issues described above are completely unacceptable if they are not due to user error (seems not).

 

Again, @NNA: Please test these tools thoroughly before releasing them. We simply can't beta-test while at the same time producing economically and legally binding building permit and construction documents. This is something that your every marketing and engineering employee has to understand completely.

 

 

 

 

 

 

Link to comment
  • 0
  • Vectorworks, Inc Employee

Just wanted to chime on this report:

1. It is recommended that your Working Files (WF) are saved locally.

2. Do not use auto saved backups of your WF with Project Files (PF) . It is best to always reopen the PF to get a new WF.

3. Do not make all users an Administrator. The original poster mentioned all users are administrators. This is dangerous. This means any team member can release the exclusive lock that another user owns on one or more objects. If this happens, that user will lose work.

 

Thanks,

Tolu

Edited by Tolu
Link to comment
  • 0
4 minutes ago, Tolu said:

Just wanted to chime on this report:

1. It is recommended that your Working Files (WF) are saved locally.

2. Do not use auto saved backups of your WF with Project Files (PF) . It is best to always reopen the PF to get a new WF.

3. Do not make all users an Administrator. The original poster mentioned all users are administrators. This is dangerous. This means any team member release the exclusive lock that another user owns on one or more objects. If this happens, that user might lose work.

 

Thanks,

Tolu

 

Hi, to clarify:

 

1.  OK.

 

2.  What happens if your WF crashes and you need to recover your work and then commit save to the PF?  If you can't use an autosaved back up of a WF what good is it?  Maybe I don't understand what you're saying.

 

3. I understand what you're saying.  Sometimes though things don't release so easily, even with custom release, so being able to override that from another user is handy.  There's only 3 of us so it isn't a problem, but I could see it being one in a larger office. Maybe we'll try to make only one administrator just to see if it improves things. 

 

To be clear, when this all works it is really great.  When it doesn't there is a significant risk of missing drawing issues / problems on printed sets that make their way out for construction.  

 

Link to comment
  • 0
  • Vectorworks, Inc Employee

2. You should always Commit and Refresh into your last saved WF. In the case that you have to recover work from a backup copy of your WF, I recommend you open the backup WF, and copy & paste information from it into your actual WF. Never "Save and Commit" from the backup copy.  

 

This is necessary because the WF stores information about which objects you own, and the changes you have made in the WF. Some of this information is also present in the PF. Specifically, the information in the WF must correlate with the information in the PF.  The information in a 3-day-old backup WF, for example, will not correlate with the information in the latest version of the PF (well, unless the PF is also 3 days old or the owner of the WF has not done any work in 3 days).

 

3. "...so being able to override that from another user is handy". Yes, it might be handy but releasing someone else's work means that other person will all lose work (i.e. the work is present in their WF but it cannot commit it into the PF). If 3 people working on the project can perform an admin release, it is difficult to identify what got released and when it was released.

Link to comment
  • 0

2.  We wouldn't recover something that old, but what does happen is you need to remover something in the last hour or so from your local drive's VW backup.  We have our autosaves set to 3 minutes, so we typically don't lose much work.  However, I do think our practice is to recover the back up file, then save as OVER the local WF, then save and commit.  Is that a problem.  

Link to comment
  • 0
  • Vectorworks, Inc Employee

If it's 3 minutes old in most cases it might not be a problem; but I would advice against it (or say be very careful).

 

Take the following scenario:

1. 12:00pm - You check out "Design Layer-1"

2. 12:01pm - You make some changes on "Design Layer-1"

3. 12:03pm - Backup of WF gets created 

4. 12:04pm - You "Close and Release" your WF and you choose to discard all changes

 

At this point, the backup WF thinks it still owns "Design Layer-1" and it has changes on "Design Layer-1" but the PF says it doesn't. This is an over-simplified example, but this is an example where the information in the backup does not correlate with the PF.  Now, you will actually get a warning (alert dialog) when you reopen the backup file. Vectorworks will detect some discrepancies like the one mentioned above.  

 

 

Thanks,

Tolu

 

 

Link to comment
  • 0

Yes, I see your point but that is not a likely scenario.  

 

IMO the most relevant and useful file is the file that was created 3-5 minutes before a crash.  For example, it is possible that our WF's would not be saved for 30 minutes, or longer, while working.  In that scenario, isn't it also possible (and likely) that the old, original WF wouldn't match the current state of the PF?  

 

That's why we grab the back up and re-name because we feel that file will most closely match the status of checked out objects and layers etc.  I also think it is impractical to paste work back into a WF from a backup, depending on what was lost. 

 

So, my scenario would be:

  1. 12:00 I open my WF and check out some layers, do some work for half an hour.
  2. 12:27 a backup is created.
  3. 12:30 I crash without saving back to the local WF.

If I open the original WF again, it will say that I don't have anything checked out.  The Backup file will though, and it is only 3 minutes old.  This is why we don't use the method you describe, of pasting work back into an original WF.  It is impractical and we'd would not think to do it that way.  Also, in the scenario I outline above, with your method, I'd have to track down 30 minutes of work in that back up file and ensure I copy it over (which can lead to crashes as well if you've ever tried it!).

 

It is possible I'm not understanding you correctly, but I think I am.  

 

 

 

Link to comment
  • 0
  • Vectorworks, Inc Employee

You make valid points; and you are correct (if you go 30 minutes without hitting Ctrl+S) your back up will have the latest information. You will be better off with a backup that is ~3mins old versus a WF that's older.

 

 

Edited by Tolu
Link to comment
  • 0

About project sharing issues in general: Do static versus dynamic IP's come into play? Should the workstations have a static IP assigned?

 

We continuously encounter issues with checking out layers (and objects). The check-outs and releases don't seem to get through to other users properly.  There seems to be some weird delays as well; VW says everything is committed and refreshed, however it takes several minutes for the changes to actually propagate to the project file.  All working files are on individual pc's and the project file is on a fast network server. There are no networking issues whatsoever that we are aware of. VW project sharing is the only software having these "networks typish" issues currently.

 

 

 

 

Link to comment
  • 0
  • Vectorworks, Inc Employee

1. Static or dynamic IP differences shouldn't come into play, but static is better actually

2. Could you please provide specifics on the issues you are seeing with "Check-outs" and "Release"? Are you getting error messages? etc.

3. When a user "Saves and Commits" into the PF, some of the work is done in the background. That is, we allow the user to continue woking while data is being transferred to the server. If you are on a 1 Gbps network, this should only take a few seconds (not minutes).

  • Are you connected to the network via WiFi or Ethernet cable? If your WiFi is on, turn it off to see if it makes a difference.
  • Are you using SSDs on the server?
  • Is the server setup using some RAID configuration?
  • Could a process be slowing down the write operations on the server (e.g. Antivirus, etc.)?

Thanks,

Tolu

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

1. Static or dynamic IP differences shouldn't come into play, but static is better actually

2. Could you please provide specifics on the issues you are seeing with "Check-outs" and "Release"? Are you getting error messages? etc.

3. When a user "Saves and Commits" into the PF, some of the work is done in the background. That is, we allow the user to continue woking while data is being transferred to the server. If you are on a 1 Gbps network, this should only take a few seconds (not minutes).

  • Are you connected to the network via WiFi or Ethernet cable? If your WiFi is on, turn it off to see if it makes a difference.
  • Are you using SSDs on the server?
  • Is the server setup using some RAID configuration?
  • Could a process be slowing down the write operations on the server (e.g. Antivirus, etc.)?

Thanks,

Tolu

2. We simply get error messages like "Layer xxx is checked out by zzz", even though it is not and even though the release/commit operation has been carried out properly, sometimes multiple attempts. I'll provide a screenshot when this happens again to give you the exact error message.

3. I concur, this is very unlikely to be a network speed issue. We actually had a network overhaul recently and it had no effect on these errors.

-The connection is ethernet, there is no WiFi at all. There are no known issues with the network.

-No SSDs, ordinary Western Digital Red disk drives

-Raid 6, Synology 1517+ server (the previous server was a Lacie Network SpaceMax in Raid 1 configuration, with the same issues)

-We run Windows10 64bit machines with built-in Windows Defender only. The server itself has no antivirus software.

 

I'll set up static IP's and see if it makes any difference.

 

The project file becomes "corrupted" somehow in regards to who has checked out and what, even if there have been no crashes or other known problems. Saving the project file as a copy .vwx and then re-sharing it always removes the "checking-out" issues, until after a week of work or so, when they surface again.

 

Thanks

 

 

Link to comment
  • 0
  • Vectorworks, Inc Employee

2. This will happen if another user has created an object on that layer.  That is another user has a soft lock on that layer.  There are 2 types of lock - exclusive lock and soft lock.  With exclusive lock, only 1 user owns that lock, and only that user can modify that object.  However, multiple users are allowed to hold soft locks on an object. These objects are always container objects, e.g. layers, groups, etc. With a soft lock, users are allowed to modify the contents of the object, but they are not allowed to modify the object directly.

  • If a user checks out an object or a layer, that object or layer is exclusively checked out to that user.  
  • If a user modifies an existing object (or creates a new object) on a layer, that object is exclusively checked out to that user. In addition, that user owns a soft lock on that layer.

Scenario:

If User1 adds a Rectangle on Layer-1, User1 owns the Rectangle and he/she has a soft lock on Layer-1. If another user, User2, adds a Circle on Layer-1. User2 then holds an exclusive lock on that Circle. In addition, User1 and User2 each own a soft lock on Layer-1.  In this scenario, no one on the team will be allowed to directly check out Layer-1 since other users already own objects (or have modified objects) on that layer. If any user goes to the Project Sharing dialog, Layer-1 will not be listed in blue because it is not checked out.  However, as an Admin, if you select Layer-1 in the Project Sharing dialog, the Release button will become enabled since there are soft locks on Layer-1 that can be released. If as an Admin you click the Release button, you will be notified that 2 users will lose work (User1 and User2 in this scenario to be specific).

 

 

3. We have heard a lot problems with Synology drives. From our internal testing, we have found that these drives do not respect exclusive read/write access when you mix protocols. Specifically, we've found that 2 users are allowed to open the same file with read/write access.  This is bad; it would most likely result in loss of work. If you search online, you will read posts from a lot of Synology users complaining about these problems (with different applications).

 

As far as RAID 6 is concerned: extra parity data must be calculated and written separately. This means your writes will be slower. I propose you eliminate the RAID configuration and see if the delay problems go away. I will also recommend SSDs (if possible) over disk drives. Project Sharing requires frequent short file I/O operations; as such, you need your write as fast as possible.

 

Thanks,

Tolu

Link to comment
  • 0

2. No, no-one has created any objects on any other layer than those that have been checked out by that particular user. I see your point but that is not how we work. We nowadays work only by checking out complete layers, since we've noticed this produces less errors.

 

The scenario is like this:

-User 1 checks out layer 1.

-User 2 checks out layer 2.

-Both save and commit/close and release.

-Let's say the next day user 1 tries to check out layer 2, but he can't since these above described errors.

 

About "soft locks" - If I try to draw a rectangle on a non-checked out layer, the software doesn't even allow this and prompts me to check that layer out. How would I be even able to do what you suggest?

 

Apparently there is no way for the users and the admin to know if there are these "soft locks" present (other than going to project sharing and selecting that particular layer and then noticing the release button is enabled)?  What if I'm out of the office for the day? No one will be able to release the layers, since they are not administrators (since there should be only one).

 

3. Synology NAS drives are one of the best in the market. I seriously doubt that what you describe is due to a faulty setup, if true. We have had no file/data issues whatsoever with any other files and particularly any non-project sharing VW files.

 

-We have no simultaneous file access problems - all files report correctly and immediately if they are open by some other user, including WV files. Additionally, the previous network drive was a Raid 1 configuration on a bit different network setup and  the VW project sharing symptoms were the same.

 

-Raid 6 is very fast when it comes to operation. Writing may be theoretically slower, but saving any VW file is just seconds.

 

-We are a professional, live architect's practice and have absolutely no possibilty to "eliminate the RAID configuration". 

 

 

 

 

 

 

 

 

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

About "soft locks" - If I try to draw a rectangle on a non-checked out layer, the software doesn't even allow this and prompts me to check that layer out. How would I be even able to do what you suggest?

In Vectorworks 2017, drawing a rectangle on a non-checked out layer will not prompt you to check out the layer. My assumption all along was that you are using Vectorworks 2017. Is that not the case?

 

Project Sharing requires frequent short file I/O operations. It's requirements are vastly different from non-project sharing files.  

 

Regards,

Tolu

 

 

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

2. This will happen if another user has created an object on that layer.  That is another user has a soft lock on that layer.  There are 2 types of lock - exclusive lock and soft lock.  With exclusive lock, only 1 user owns that lock, and only that user can modify that object.  However, multiple users are allowed to hold soft locks on an object. These objects are always container objects, e.g. layers, groups, etc. With a soft lock, users are allowed to modify the contents of the object, but they are not allowed to modify the object directly.

  • If a user checks out an object or a layer, that object or layer is exclusively checked out to that user.  
  • If a user modifies an existing object (or creates a new object) on a layer, that object is exclusively checked out to that user. In addition, that user owns a soft lock on that layer.

 

 

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.  This object will not show up under the main project sharing window (which is should).  It is getting confused.  What we find is that a user may have an object checked out, but the layer released.  In this scenario another user can't check out the layer until the other user does a custom release of the entire file.  Maybe we'll start using the colours.

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...