Jump to content

Tolu

Vectorworks, Inc Employee
  • Content Count

    335
  • Joined

  • Last visited

Community Reputation

27 Great

1 Follower

About Tolu

  • Rank
    Journeyman

Personal Information

  • Location
    Columbia, MD, USA

Recent Profile Visitors

637 profile views
  1. I'm going off of your previous statements, which was that a ”Save and Commit” takes 15mins and that for 3 users it equates to 45 mins. At any rate, the time for a S&C or Refresh is completely dependent on the changes you've made, your hardware, & network speed. I’ll investigate using your files tomorrow morning and follow-up with you.
  2. Clearing the metadata does not require a ”save and commit”. It only requires that all users refresh their WFs. All the users within the team can refresh at the same time.
  3. Importing data from consultants that use other software can cause your User Origins to shift if you do not select the correct options when importing their files into Vectorworks. A shifted User Origin will cause your referenced data to appear at the wrong location. If you see a "random" shift, make sure the User Origin in your source and target files are correct. Once you have validated the User Origin, you should update all references. If, after following these steps, your files still appear shifted, please send me your files in a Direct Message. I will investigate the problem further.
  4. Unfortunately, I am unable to follow your message. The video you posted in blurry. I cannot see your screen. This message is a warning that the performance of Project Sharing is degraded because your Project Sharing metadata is too large. As such, many Project Sharing operations will be slow. This message is meant for an Administrator that understands the next steps (i.e. clearing the metadata). You can read about clearing the metadata here: https://app-help.vectorworks.net/2019/eng/index.htm#t=VW2019_Guide%2FProjectSharing%2FClearing_Metadata_from_the_Project_File.htm&rhsearch=Project Sharing metadata&rhsyns=
  5. If a user has two machines with the same name, VW will allow the user to use the same Working File on both devices. The user would need a way to transfer his or her WF across both machines. If the user is working at home, and he checks out ten objects, once he transfers his WF to his work machine, the same ten objects will be available to use from that same WF. The user must be careful with this workflow. He or she must always work on the latest copy of his WF. As such, the user needs to find a mechanism to sync his WF automatically to both machines, or he must put his WF on a USB drive. If you do not want this behavior, you will need to create another user account on one of the machines. With this, you will see the user as two users in the Project Sharing dialog. Even with this workflow, the user must not forget to release objects when he is done working at home. If he does, he will block himself (when he is back at work) and other users.
  6. I just tried PS and Dropbox on my end here, and everything works correctly. I do not see any problems.
  7. This problem should be fixed now. Users should be able to use Project Sharing with Dropbox, Box, etc.
  8. I’m looking into this now. Was tour Dropbox client upgraded over the weekend?
  9. If you change the User Origin in a Project Sharing environment, it is logged in the history.
  10. The "Network Protocol" setting is stored with the Project File -- not the Working File. The admin has to change it by opening his Working File, going to File -> Project Sharing... -> Settings tab. Once modified, the change will be reflected in all users' Working File associated with that Project File. Changing this setting requires "administrative" permissions, so all users will not have permissions to change this setting. If every user is an admin, this is bad.
  11. Ah yes, you need to change the Network Protocol for each Project File from AFP to SMB via the Project Sharing dialog. This applies only to VW2019 Project Files. There is no utility to change all Project Files at once. Yes, because you have changed the protocol, VW is complaining..... but this not a "file locking" issue as you originally put it. Thanks, Tolu
  12. Could you please elaborate on what you need to change per-project? A file that has references does not store the protocol used to connect to the share or NAS device. The file stores the path. On Mac, the path is similar to this: /Volumes/ShareFolder/path/to/source.vwx On Win, the path is similar to this: \\Server\ShareFolder\path\to\source.vwx As such, you switching from AFP to SMB does not require any changes to the File. Side note: The Mac allows you to mount a shared folder in multiple ways. For example, if the admin has shared a file at smb://OurServer/SharedFolder/WGR/File.txt. On the Mac, I can mount the Share in multiple ways (using Cmd+K). I can mount it as "smb://OurServer/SharedFolder/" or as "smb://OurServer/". Essentially, a user is allowed to specify his/her mounting point. The different mounting points will result in different paths to the text files. For the first mount, the path will be /Volumes/WGR/File.txt. The path to the 2nd mount will be /Volumes/SharedFolder/WGR/File.txt. If the text file was a vwx, you could imagine how specifying different mounting point will prevent the target file from automatically finding the source file. You can get around this issue by making sure all users on the team use the same mounting point, or you can use relative paths. With relative paths, VW will neglect the mount point. The only requirement when using relative paths is that the source and target file must be on the same volume. I don't know about your NAS device, so I can't speak about what you've experienced. In our tests, we have only found that when you connect to a Synology NAS device using different protocols, the file locks (read and write (R/W) locks) are not respected. That is, if a user opens a file for R/W using SMB, another user can open the same file for R/W using AFP. This error is why we strongly recommend using only one protocol. We have never seen the case where two different users using the same protocol is allowed to open the same file simultaneously. If you have a reproducible example, I will be glad to set up a screen sharing session to see what is happening. It is essential to point out that a user can connect to the same share using SMB and AFP at the same time. You should "Get File Info" (Cmd+I) on the file through the Finder window to see the protocol in use. Thanks, Tolu Vectorworks Inc.
  13. Admin Release is not a temporary change. The alert following an admin release warns you that the user would lose their work if they have uncommitted changes. This is one of the reasons why we strongly recommend have only 1 (max 2) admin in a Project. Has someone else modified the objects that you "Admin Released"? If so, you would have to decide how you will merge the changes (someone might have to redo their work). If no one has modified the objects, the user can have to get a new WF, and then paste the objects from the old WF into the new WF. Note with copy and paste, any previous work done to those objects that are not in the old WF will be overwritten.
  14. @tomk @Jeremiah Russell Hi Jeremiah and TomKen, Are the walls that become unjoined all on the same layer, same classes? Do you know if those walls were recently modified? Thanks.
  15. Could you please provide more information on your setup - the version of VW you are using, server type and version, connection, etc.? Thanks

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...