Project Sharing Bugs

[rb-arch]

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. 

[Guest Tolu]

1 hour ago, JMR said:

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?

Your WF should never become corrupt because we use "Safe" saves. You will never lose your data. ...but in the event that it happens, yes, the best solution is to do what you said. Open a new WF and copy over your data into the new WF.  

[Guest Tolu]

1 hour ago, rb-arch said:

1 hour ago, rb-arch said:

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.

 

 

Absolutely! You can do that today though. You can set your Autosave setting to “Overwrite original file.” It is much like you hitting Ctrl+S (or Cmd+S) every x minutes. 

 

I would not recommend every 3 minutes since there will be resource contention. Furthermore, you will be unable to work every 3 minutes because changes are not allowed during file save. However, if this works for your team, you can do that.

[rb-arch]

5 minutes ago, Tolu said:

Absolutely! You can do that today though. You can set your Autosave setting to “Overwrite original file.” It is much like you hitting Ctrl+S (or Cmd+S) every x minutes. 

 

I would not recommend every 3 minutes since there will be resource contention. Furthermore, you will be unable to work every 3 minutes because changes are not allowed during file save. However, if this works for your team, you can do that.

Wow, of course!   I think I had that checked on years ago and stopped doing it that way.  Since we started using Project Sharing we've never really revisited this tab other than to change the auto save settings.  So thank you for the reminder, from a long time user LOL.......   🙂

 

Lately in our discussions here, we've also sort of agreed that we very rarely get any use out of the auto save back up files because it is just too onerous to cut and paste *certain* types of work.  

 

Thanks.

[Boh]

On 8/1/2018 at 12:13 PM, Boh said:

 

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

 

Thanks for the responses to the above. It seems there is still no ideal solution to backing up working files in case of crashes.

 

VW has always crashed periodically on me over the years. It's just something that I've got used to and have to work around. Part of that work around for me is an auto backup every 5 minutes which is pretty efficient as long as VW isn't crashing all the time.

 

However (in summary):

• it's not recommended practice to overwrite original WF's with backups.
• Copying & pasting work from a recent backup to an original working file is a real pain in the @#**
• You can reset your VW preferences to auto-save over the original file instead of create backups however to have to pause work every 5-10 minutes while an auto save is carried out isn't really acceptable. Also I don't want to have to reset my preferences to accommodate the one job I'm working on which uses project sharing. Toggling my auto-save preferences each time I switch to working to a WF isn't going to happen. 

There doesn't yet seem to be the perfect answer for this. Unless VW can produce a product that they can guarantee will never crash then they need to provide a smooth and efficient backup procedure for all file types.

[Boh]

I just had my first crash with my project sharing file 😞 But found this Project Sharing guide on the Nemetschek VW website:

http://download2.nemetschek.net/www_misc/workflows/Introduction+to+Project+Sharing.pdf

 

Page 39 has a procedure for using backup files however it says:

 

 

Not sure this is correct as when I try to check out layers on my backup working file it says I first have to refresh. Refreshing of course will mean I will lose the changes....

 

Is this correct? Looks like I'll have to do a cut & paste to get my file up to date....

 

[Guest Tolu]

Is your backup file newer than your original WF? Because you crashed doesn't mean you need to use your backup. 

 

If the layer/object you checked out is out of date, yes, Vectorworks will prompt for a fresh first. This seems to be the case with your back WF.

 

The excerpt you mentioned in the guide is from ”how to replace a current working file with a backup file.”    The first step reads, ”Release all objects and layers in the current WF”. By the time you get to step 5, none of the layers/objects in your backup file will be checked out, so the documentation is correct. 

 

Thanks

[Boh]

55 minutes ago, Tolu said:

Is your backup file newer than your original WF? Because you crashed doesn't mean you need to use your backup. 

 

Yes the backup is more recent than the crashed working file. I should get in the habit of saving my file more often, instead my workflow has been to have a auto backup every 5 min

58 minutes ago, Tolu said:

The excerpt you mentioned in the guide is from ”how to replace a current working file with a backup file.”    The first step reads, ”Release all objects and layers in the current WF”. By the time you get to step 5, none of the layers/objects in your backup file will be checked out, so the documentation is correct. 

 

Thanks

Hmm. Yes I want to replace the crashed working file with a more up to date backup.  Where did I go wrong?

my working file crashed.

i reopened it and committed all changes to the project file. 

I then released all layers that were checked out.

 

i thought I could then open the backup working file, check out the same layers I released friom the original file and commit the changes. 

 

VW says this isnt possible without a refresh which as mentioned will mean I lose my uncommitted changes.

[Guest Tolu]

9 hours ago, Boh said:

i thought I could then open the backup working file, check out the same layers I released friom the original file and commit the changes. 

 

VW says this isnt possible without a refresh which as mentioned will mean I lose my uncommitted changes.

You cannot check out a layer/object that is out of date. This is working as expected.

[Boh]

ThanksTolu. Appreciate the response. Still confused however....  For now I will stick to the laborious cut-and-paste-from-backup technique when trying to retrieve unsaved/uncommitted changes to a crashed working file. 

[rb-arch]

8 hours ago, Boh said:

ThanksTolu. Appreciate the response. Still confused however....  For now I will stick to the laborious cut-and-paste-from-backup technique when trying to retrieve unsaved/uncommitted changes to a crashed working file. 

 

You're going through the same learning curve we did about 4 months ago.  In project sharing, it is our opinion that the auto save files are essentially useless.  Cutting and pasting changes doesn't really work in practice.  

 

As discussed above, we now set our autosaves to *overwrite* the WF.  This gets around the cutting and pasting and keeps the relationship in tact between the WF and the PF.  Lastly, it does seem to be intuitive to take the backup file and "save as" the WF, but this seems to be a bad practice according to Tolu.

[Boh]

I am wondering if there been any improvement in best practice for retrieving work from backup files for project sharing since this was last responded to?

 

What is the current best practice? We are now using vw2019 and we still seem to have the issue of trying to retrieve stuff from backup files. We would appreciated any info. 

 

Would upgrading to vw2020 make any difference?

 

Thanks in advance.

[rb-arch]

12 hours ago, Boh said:

I am wondering if there been any improvement in best practice for retrieving work from backup files for project sharing since this was last responded to?

 

What is the current best practice? We are now using vw2019 and we still seem to have the issue of trying to retrieve stuff from backup files. We would appreciated any info. 

 

Would upgrading to vw2020 make any difference?

 

Thanks in advance.

Retrieving data from a backup was never really practical in a real workflow - for us anyway.  We now set our autosave to overwrite the original file every 50 operations.  This way the shared file is the correct one, and at worst you're out 50 operations.  Nothing else worked for us, reliably.  I'm not sure what the VW engineers think about this, but that's what we do.  As stated above, and to them directly, trying to retrieve work from a back up when you're hoping all over a building is impossible. 

[Boh]

Thanks @rb-arch

Do you retain the same preferences when you are not using project sharing?

 

As you don't have any backup files what do you do if a file not only crashes but gets corrupted? Or has this not happened?

[rb-arch]

1 minute ago, Boh said:

Thanks @rb-arch

Do you retain the same preferences when you are not using project sharing?

 

As you don't have any backup files what do you do if a file not only crashes but gets corrupted? Or has this not happened?

 

We do keep the same settings and if we get a corruption we get a back up from the server or time machine from the workstation.  Those are rare for us though.