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
  • Vectorworks, Inc Employee

If your Project Sharing Setting is configure to only allow SMB connections then you must connect to the share containing your PF using SMB.  

 

This alert is saying you are connected to the PF using AFP but the Project Sharing Setting is configure to only allow SMB connections.

 

Note that the MacOS allows you to connect to a sever using both AFP and SMB (at the same time). Essentially, the PF will appear as separate files - they will have different file paths.  As such, you should make sure you are connected to the server using the correct protocol (try using cmd+K and specify the correct protocol). Also you should make sure you are using the correct path. 

 

I actually recommend that you configure your Mac mini server to only accept connections for a specific protocol - AFP or SMB, but not both.

Link to comment
  • 0

Have there been any updates on the NAS reliability front?  My office needs to replace our server, and we're looking into whether we get a new server, or a NAS setup.  We do (attempt) to use project sharing on our larger projects.

 

We are a Mac based office, so the server would probably be a Mac Mini server.

Link to comment
  • 0
  • Vectorworks, Inc Employee

 

11 minutes ago, ptoner said:

I am being told the Project file is in use, by another user when no one else has it open!

On what type of server is your Project File located?

 

Check that your PF is indeed writeable. Vectorworks shows that message whenever it is unable to write to the PF

Link to comment
  • 0
  • Vectorworks, Inc Employee

@AsemblanceI'm interested in learning more about your problem. 

 

Every Working File stores the path to its associated Project File - that's the only connection a WF has to its PF. A WF cannot "disassociate" from the PF.  

 

As long as you are connected to the server, the WF should be able to access the PF. However, the PF must be writeable before changes can be made in it.

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

 

On what type of server is your Project File located?

 

Check that your PF is indeed writeable. Vectorworks shows that message whenever it is unable to write to the PF

Server is running OSX Server, on a maxxed out Mac Mini Spec. We are all running OSX on iMacs OSX 10.13.3 and have 40 stations. 
This is the first time I have used workgroup sharing as a test and clearly, it is not fit for purpose. 

Some how the permissions on the on the PF changed to read only. As IT admin also, I changed the permissions for the file back to read/write. Still would not work.

At this stage due to the unchecked out layers and the above issue, none of the staff in my workplace will be using this feature.
Do not have time on quick turn around projects to waste time on bugs like the above. 

We were working form a WF located on the local machines with the saves and commit being copied to the PF on the server. Network speeds are not an issue. The software is.
 

Edited by ptoner
Link to comment
  • 0

@Tolu

 

Unfortunately whether or not it can 'disassociate' this is in effect what it sometimes does in reality!

 

I have discussed my issues with project file sharing before elsewhere on the Forum, essentially the answer seemed to be to do with connections to NAS servers.

 

However looking at the above it may be that this is not the case if people are suffering on other types of servers also.

Link to comment
  • 0
  • Vectorworks, Inc Employee
2 hours ago, ptoner said:

Some how the permissions on the on the PF changed to read only.

This is a symptom of improperly configured user permissions on the Mac Server. Have you tried enabling “Direct Safe Save”? This can help when your user permissions are improperly configured. This option is available under the Settings tab of the Project Sharing dialog. By the way, all users need full access to the shared folder. 

 

Did you configure the PF to only accept a specific protocol? If so, which protocol did you choose?

Link to comment
  • 0
  • Vectorworks, Inc Employee
11 minutes ago, Asemblance said:

@Tolu

 

Unfortunately whether or not it can 'disassociate' this is in effect what it sometimes does in reality!

 

I have discussed my issues with project file sharing before elsewhere on the Forum, essentially the answer seemed to be to do with connections to NAS servers.

 

However looking at the above it may be that this is not the case if people are suffering on other types of servers also.

I wouldn’t assume that the root cause of the problems you are seeing on your NAS device are the same as @ptoner’s problems. 

Link to comment
  • 0
54 minutes ago, Tolu said:

This is a symptom of improperly configured user permissions on the Mac Server. Have you tried enabling “Direct Safe Save”? This can help when your user permissions are improperly configured. This option is available under the Settings tab of the Project Sharing dialog. By the way, all users need full access to the shared folder. 

 

Did you configure the PF to only accept a specific protocol? If so, which protocol did you choose?

We use Xserve RAID for storage of files.

I will look into the "Direct Safe Save".

 

We selected AFP as SMB on a mac network creates directory issues.

Edited by ptoner
Link to comment
  • 0

Hi @Tolu

 

Thanks for attempting to help with this. But yes we have tried 'direct safe save', and using AFP (as suggested for Mac users).

 

We've pretty much been through this process with Vectorworks select support and also on the forums previously, and the conclusion seems to be that it is a problem with the software (probably in conjunction with NAS servers)

Link to comment
  • 0
On 8/24/2017 at 7:26 PM, JMR said:

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.

 

 

 

Has project sharing changed since the above was posted? Could working files not be auto-backed up in VW preferences?

 

I am brand new to project sharing and have just started trialing it on a project. I have read through this thread and there is a lot of good info.

 

I am a bit confused though about saving backups of working files and the best process for ovewriting a crashed working file with it's more up to date backup without losing/messing up the links to the project file. 

I.e. in this scenario:

My auto save settings create backup files of working files every 5minutes.

If after editing a working file without committing changes for say 30 mins my VW crashes.

Can I simply open the most recent backup and overwrite the working file with it and then commit changes back to the project file?

 

Link to comment
  • 0

As per instructions from NNA and other users, we now keep working files on individual pc's. Only the project file is on the disk server.

 

The working files are backed up to the same computer where they reside on.

 

In case of a crash you describe, I've successfully opened a working file backup and saved it over the working file.

 

As to ongoing issues, a few days ago we experienced the shifting walls problem again, in these cases the situation is remedied by saving a copy of the most current working file as an ordinary .vwx file and then re-sharing it. I'm going to bug-submit this when I can make the time.

 

We still experience frequent issues with crashes, checkouts, commits and title block borders. Project sharing is still very buggy, though there has been improvement from the earlier versions.

 

Oddly project file updating is extremely slow in 2018 for some reason.

 

 

  • Like 1
Link to comment
  • 0
8 hours ago, Boh said:

 

Has project sharing changed since the above was posted? Could working files not be auto-backed up in VW preferences?

 

We now open the master and then save the workfile locally onto the desktop of the users machine. Also in Vectorworks setting we have 4 backups saved locally on each machine after 40 operations. The master file will always be updated on the server and backed up form there, as per or office policy. It does not hurt though to duplicate that master, every so often, in case of corruptions. 
The check out or read/write issues are now at an all time low. but we have been very reluctant to use Workgroups due to previous issues.
We also have been using forced AFP for over a year now on all network transfers.

 

Edited by ptoner
Link to comment
  • 0
15 hours ago, JMR said:

As per instructions from NNA and other users, we now keep working files on individual pc's. Only the project file is on the disk server.

 

The working files are backed up to the same computer where they reside on.

 

In case of a crash you describe, I've successfully opened a working file backup and saved it over the working file.

 

As to ongoing issues, a few days ago we experienced the shifting walls problem again, in these cases the situation is remedied by saving a copy of the most current working file as an ordinary .vwx file and then re-sharing it. I'm going to bug-submit this when I can make the time.

 

We still experience frequent issues with crashes, checkouts, commits and title block borders. Project sharing is still very buggy, though there has been improvement from the earlier versions.

 

Oddly project file updating is extremely slow in 2018 for some reason.

 

 

We've had all these problems, and solid operations not reporting to the PF, Legend text going to zero point, walls un-joining, etc.  

 

We've also recovered auto save files and overwritten Working Files, but were instructed by Tolu to not do that.  Generally, we still find it to be buggy, but when it works it is great.

Link to comment
  • 0

Spoke too soon, the first project that we commenced on, after a period of not using workgroups, and the dreaded not releasing of layers has happened again. Scrap master file and rebuild process from a workfile. 

Really getting quite pathetic this process and wasted time rebuilding. 

Link to comment
  • 0
  • Vectorworks, Inc Employee

@ptoner

One of your colleagues must be overwriting his/her WF causing objects to be locked out. Objects are checked out to a user in a specific WF. You can’t simply delete or overwrite the WF. Also, you should reuse your WF (i.e. reopen your local WF in the morning). Do not open the PF directly. Doing that will create a new WF.  

 

In the event that someone deletes/overwrite their WF without performing “Close and Release”, if you have admin rights, you can Admin Release the layer(s).  Go to the Layers tab of the Project Sharing dialog, select the layers one at a time and check if the “Release” button is enabled. If it is, click “Release” to remove the exclusive lock.

 

There is a wealth of resources on this forum on how to properly use Project Sharing: 

https://forum.vectorworks.net/index.php?/search/&q=“Project Sharing”&type=cms_records1&search_and_or=or

 

Regards,

Tolu

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

@ptoner

One of your colleagues must be overwriting his/her WF causing objects to be locked out. Objects are checked out to a user in a specific WF. You can’t simply delete or overwrite the WF.


Every morning they open the local workfile and continue working. We have never deleted the workfiles and created a new one. We always use the originally created workfile. 

 

 

2 hours ago, Tolu said:

In the event that someone deletes/overwrite their WF without performing “Close and Release”, if you have admin rights, you can Admin Release the layer(s).  Go to the Layers tab of the Project Sharing dialog, select the layers one at a time and check if the “Release” button is enabled. If it is, click “Release” to remove the exclusive lock.

 

This is the issue, when this happens the layers in the admin account and his workfile, and the others, do not show the layers as being checked out. So if they are not showing as being checked out, you cannot release anything. Hence why we have to delete all workfiles, and create a new master from the latest workfile that someone was workign on.

 

2 hours ago, Tolu said:

There is a wealth of resources on this forum on how to properly use Project Sharing: 

https://forum.vectorworks.net/index.php?/search/&q=“Project Sharing”&type=cms_records1&search_and_or=or

 

Thanks for the link... still does not work as it should though. 

Link to comment
  • 0
  • Vectorworks, Inc Employee
4 hours ago, ptoner said:

This is the issue, when this happens the layers in the admin account and his workfile, and the others, do not show the layers as being checked out. So if they are not showing as being checked out, you cannot release anything. Hence why we have to delete all workfiles, and create a new master from the latest workfile that someone was workign on.

If user1 has a rectangle on Layer1 checked out, it does not mean user1 has Layer1 checked out. As such, the Layers tab of the Project Sharing dialog will not show Layer1 has being checked out.

 

Now, if you have the above scenario, you (as an admin) can still go the Layers tab of Project Sharing, select Layer1, and you will see that the “Release” button is enabled...again, Layer1 will not be shown as checked out (because it is in-fact not checked out), but the ”Release” button will be enabled. 

 

It is essential to understand the concept of soft lock versus exclusive (or hard) lock. In the above scenario, user1 has a soft lock on Layer1, but an exclusive lock on the rectangle. If user2 adds a circle on Layer1, then user2 will have an exclusive lock on the circle and a soft lock on Layer1 (in addition to user1’s soft lock on Layer1). Essentially, multiple users can have soft locks on the same container-like object (Layers, Groups, Viewports, etc.), and this happens when users have modified, inserted, or removed objects in the container.  When a soft lock exists on a container, no other user can directly check out the container (i.e., an exclusive lock is prevented). I think this is what's happening in your case.

 

If all users are using the same WF, then VW should tell you the user that has the object(s) checked out.  That user should run the “Close and Release” menu command so that all blocked objects are released. If this is not happening, please send me a direct message with your files in the “bad” state.

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

 

@Tolu:

 

If backing up the working file is not recommended, how to get back the lost work since the working file crashes several times daily? Commit every 20 mins to the project file?

 

Your WFs have a uuid, so I'm very opposed to anything that overwrites your WF. If you want to prevent down stream problems, I recommend you copy missing data from the back up file into your real WF. Do not save over or overwrite your WF. This might mean hitting (cmd+s) more often. 

 

I would like to understand why Vectorworks is crashing multiple times a day, however. This is the underlying problem we need to resolve. Do you have ”Error Reporting” turned on in VW Preferences dialog? If not, could you please turn it on, and then send my a direct message with the last 6 digits of your serial number?  I can analyze your crash logs to understand why VW is crashing frequently. 

 

Thank you,

Tolu

Link to comment
  • 0

Thanks, sent the serial numbers to you.

 

What if, the working file becomes corrupt due to a crash? Is it then ok delete the working file, open a new working file from the project file and copy any missing information from a working file backup to the new working file?

 

 

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

Your WFs have a uuid, so I'm very opposed to anything that overwrites your WF. If you want to prevent down stream problems, I recommend you copy missing data from the back up file into your real WF. Do not save over or overwrite your WF. This might mean hitting (cmd+s) more often. 

 

I would like to understand why Vectorworks is crashing multiple times a day, however. This is the underlying problem we need to resolve. Do you have ”Error Reporting” turned on in VW Preferences dialog? If not, could you please turn it on, and then send my a direct message with the last 6 digits of your serial number?  I can analyze your crash logs to understand why VW is crashing frequently. 

 

Thank you,

Tolu

 

We've had many discussion in the last year Tolu, and you've helped us get things running smoother and I hope we've helped highlight some software issues.  One thing I would like to request is and auto save of the WF, that overwrites the WF just like it would if you hit Save manually.  Unless you use this software to actually produce drawings I don't think you can fully appreciate what a pain it is to cut and paste from a back up file.

 

We used to set our Autosave to 3 minutes, and when we crashed, we'd take the Autosave file and save it as our "most up to date" WF.  For reasons you've explained (technical ones I don't understand), this is a bad idea.

 

If there was an Autosave WF that would overwrite as I describe above, in theory you'd only lose 3 minutes of work (or your preferred setting) and you'd retain the uniqueness of the UUID number for the WF - to keep its continuity.

 

Just a thought from a long time user.

 

Randy

 

 

 

 

  • Like 1
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...