Ongoing Project Sharing Issues: A record from one issue to another.

[Amorphous - Julian 162]

We have getting a chronic project sharing problem . Model objects, viewports and sheets regularly disappear from our shared project file. 

 

No matter the size and complexity of the file, we get this problem.

 

This happens between 1-2 times a week across different projects. 

 

Anyone else getting this issue? Is this something Vectorworks can fix in upcoming releases?

 

----------------------------------------

 

Some background:

- Our shared server runs Mac OS Server 5.2 on Mac OS 10.11.6 El Capitan, with 'SMB Sharing only' turned on in File Sharing.  

- We tried upgrading our server to Mac OS 10.13 and Mac OS 10.14, but permission issues were even more severe (in both SMB and AFP).
- We then downgraded back to Mac OS 10.11

- Previously, when we ran File Sharing on AFP in Mac OS 10.11, this 'disappearing model' issue didn't seem to occur. 

- Due to other services we have to run, we had to switch File Sharing over to SMB from AFP

- Sharing files in Mac OS with both 'AFP and SMB' turned on doesn't work, and not recommended by our Vectorworks distributor.

 

 

Edited October 29 by Amorphous - Julian
Changed the title to reflect the evolving project sharing issues.

[Amorphous - Julian 162]

(posting an update on this issue)
Just now, one of our shared files had EVERYTHING disappear from it. 
The file had NOTHING left inside. 
One of the three people sharing the file had to dig up their backup to save a version back into the server. 

[Amorphous - Julian 162]

UPDATE:

 Today we had three people work on one project file

(1) Worker A was working on Living Room

(2) Worker B was working on Laundry 

(3) Worker C was working on Skylight

Once synced (VW shows no error on syncing), none of the workers can see the other's changes and work. 

We end up having to save a completely new version of the VW shared project file, and manually 'copy and paste' all the changes back in.

This doesn't seem to work like 'sharing'.

THIS REALLY DOES HAPPEN A LOT!!!

Is our problem caused by us being on Mac but sharing via SMB? 

Are we the only practice with this issue?

 

[Amorphous - Julian 162]

UPDATE AGAIN:

Upon saving the new project file and copying everyone's work into it.

All of the previous Saved Views disappeared. The whole list is now blank.

This is scary as we do not know which other part of our Project File may also suffer from data loss.

[Amorphous - Julian 162]

Hi. UPDATE AGAIN

In our VWXP project file, which is 2GB in size and has lots of info in it. EVERYTHING DISAPPEARED. 

Yes, not a thing is left. 
Reverting back to an older version now. Terrible workflow. Terrible waste of time. 

Edited September 17 by Amorphous - Julian
text

[Amorphous - Julian 162]

Another update. 

File version 272 (as above) that we saved before of the disappearing issue worked for a few hour. 
And now we get 'file is corrupt' error message on the another terminal (this one is in windows), some users can't sync into project file. 
Reverting to backup before this error message. The joys of it all. 

[Amorphous - Julian 162]

It's 9pm now. And we just had more issues:

 

Viewports that  User A was working on DISAPPEARS on User B's and User C's computers

Viewports that  User B was working on DISAPPEARS on User A's and User B's computers

Viewports that  User C was working on DISAPPEARS on User A's and User B's computers

 

We have to revert to a much older version and re-do everything we have been doing for the last 3.5 hours. 

 

THIS IS RIDICULOUS. If my staff departs form my office because of Vectorworks, guess who's fault is it?
I already hear people saying 'I'm so tired, so tired of this'.
I HAVE BEEN TALKING ABOUT PROJECT SHARING ISSUES SINCE VW2018.
Now have have gone through VW2019 SP1, SP2, SP3, SP4, SP5 and onto VW2020. 

What exactly must we do or say to get an efficient, reliable program for what we need to do???

 

By the way, it is really not fun to waste my time documenting this and posting it up. 

[Amorphous - Julian 162]

Update: 
(1) We got the 'this file is corrupt' message today doing a Save and Commit to the project file, and the team lost a lot of work again. 
(2) Our distributor suggested we use 'Dropbox LAN sharing' to resolve this issue. Didn't work. See enclosed error screenshot. This didn't work. 
(3) Vectorworks tech has reached out to us to see if they can replicate the issue. Not sure what will resolve from that. 
Just on a personal note, I feel quite broken, exhausted and disheartened by all these Project Sharing issues... 

 

cid:B454F562-F8D1-45D0-9035-66586585A3BF

[Amorphous - Julian 162]

[UPDATE 18/10/2019]
The crazy crash plus disappearing viewport issue happened again today. 
Then suddenly all four of us couldn't get a file we can work with, and have to revert to 3 hours ago. 
Then manually copy and paste model/viewport things we did for the past few hours. 
This equals to 4 hours x 4 poeple's work day. 16 hours. 

 

[Amorphous - Julian 162]

[UPDATE 28/10/2019]

Project sharing issues has gone from moderate to SEVERE. To a point where project sharing is NOT FEASIBLE. 

I was out of my office on Wednesday and Thursday. 

And the following Message came up on one the workstations:

We followed the instructions. 

Follow that. 'Save and Commit' Operation will not function properly. 
It took more than 10 minutes to complete the operation. Others cannot save and commit even with 1 hour operations.
See enclosed video. (filesize reduced but I can share original)

I told the office to quickly upgrade to version 2020 to resolve the issue. 

 

----------- AFTER 2020 upgrade-----------

On Thursday and Friday, we and some staff away. So we didn't test the save and commit operation. Only one person was using the file. 
On Friday, before we left the office, we opened a project file on another terminal and tested the save and commit operation.

We left that running for the weekend.

You can see screenshot below, it is now Monday, and we have ran the save and commit ran all weekend now. 'Beachballs' don't show up on screenshots.

The beachball is still running, and the 'refresh' button still has the yellow hazard sign (it is not udpated)

I honestly don't know what to do with this now. A project that I am meant to have 4 people working on now only has one person working on it. HELP!!!!!!!

 

[Tolu 26]

Unfortunately, I am unable to follow your message. The video you posted in blurry. I cannot see your screen. 

 

13 hours ago, Amorphous - Julian said:

[UPDATE 28/10/2019]

Project sharing issues has gone from moderate to SEVERE. To a point where project sharing is NOT FEASIBLE. 

I was out of my office on Wednesday and Thursday. 

And the following Message came up on one the workstations:

We followed the instructions. 

Follow that. 'Save and Commit' Operation will not function properly. 

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=

 

[Amorphous - Julian 162]

[UPDATE 28/10/2019]
Hi  @Tolu 

Around 6 hours prior to your above response- got that metadata error message again (5pm on 28/10/2019).
The extremely slow save and commit times on this file, in combination with this meta file error, caused me to send everyone home early (See screen shot).

 

To clarify the situation, for avoidance of confusion:

(1) We had followed exactly the steps to clear metadata the first time around on Thursday (24/10/2019)

(2) This metadata error occurred again on 28/10/2018, just two working days after the first error occurred

(3) What is preventing the team from effectively executing the metadata clearing, is the 15+ minute ‘save and commit’ time required (for each person). There were 3 people in the office working on that file. That’s 45 minutes. We are rushing through documentation for this project.

(4) After the 28/10/2019 incident (where i asked everyone to go home). our manager stayed back to perform 'save and commit ' on everyones terminal, and performed the metadata clearing. the save and commit on each terminal is 15+ minutes.

(5) other files, still small in size (fee hundred MB) can still save and commit as normal 

 

We are rushing against deadlines to deliver this project. I beg you with all sincerity to give us a solution ASAP. Many thanks.

Edited October 28 by Amorphous - Julian

[Amorphous - Julian 162]

6 hours ago, Tolu said:

Unfortunately, I am unable to follow your message. The video you posted in blurry. I cannot see your screen. 

 

the video was only meant to demonstrate/prove that the save and commit profess was taking kore than 10+ minutes, it  should have little influence over the reading of the my post.

the original 260mb file won't upload due to forum file size restrictions. i have to use online converters to make screen recording video conversions just to prove my points this is very time consuming.

[Tolu 26]

2 hours ago, Amorphous - Julian said:

3) What is preventing the team from effectively executing the metadata clearing, is the 15+ minute ‘save and commit’ time required (for each person).

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.

[Amorphous - Julian 162]

6 minutes ago, Tolu said:

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.

perhaps it’s important to NOT miss the point here- either ‘save and commit’ or refresh is taking a ridiculously long time. 

Dismissing this important point doesn’t solve any issues on my end- the issue is the same

[Tolu 26]

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. 

[Amorphous - Julian 162]

Hi @Tolu I'll send you the latest file, so you can test with the appropriate evidence.

 

36 minutes ago, Tolu said:

the time for a S&C or Refresh is completely dependent on the changes you've made

The save and commit changes were related to changes made in a 1-hour period. 3 of us were out for a meeting till 4pm. 1 person was working for the whole day.
When the others returned they continued doing other bits of work, by 5pm, they had that issue. 
 

37 minutes ago, Tolu said:

your hardware, & network speed. I’ll investigate using your files tomorrow morning and follow-up with you. 

 

Our network is 10Gbe equipped and achieve real-life write/read speeds of 750MB/250MB (see screenshot). 

All our terminals have:
- NVMe drives locally,  and have write/read speeds exceeding 1250MB. 
- All terminals have either 48GB or 64GB RAM 

- All terminals have dual X5680 or dual X5690 CPU 

- All terminals have 10GBe network cards, achieve real-life write/read speeds of 750MB/250MB

- The all terminals (server and workstations) are mac-based

- Our server is Mac OS 10.11 running SMB file sharing

 

Our equipment is reasonable for an office our size. Let us know what equipment you do your tests with.

 

23 hours ago, Amorphous - Julian said:

[UPDATE 28/10/2019]

Project sharing issues has gone from moderate to SEVERE. To a point where project sharing is NOT FEASIBLE. 

 

[IMPORTANT NOTE 1]

The above 'slow save and commit issue', which I reported on on 28/10/2019, but are actually issues that happened on 24/10/2019, occurred after our upgrade to VW2019 SP5.3. 

As you know, we have had reasonable 'save and commit' up to this point (1-2 minutes). But it was never slow like this. 
We thought the issue might be related to SP5.3, so we then went up to V2020. Didn't resolve the slow save and commit. 

 

3 hours ago, Amorphous - Julian said:

 

(5) other files, still small in size (fee hundred MB) can still save and commit as normal 

 

[IMPORTANT NOTE 2]

 

In case our issue is 'not replicable' and faces dismissal (can be very distressing)-  Kindly note the above point in my post: my other files are working as normal, and save and commit times are just a few seconds.

It is the big file (which I have by now sent you the latest version). That has this problem. 

[Amorphous - Julian 162]

[UPDATE 29/10/2019]
 

This is the 'Save and commit' on one of our terminals at 5pm today, after 5 hours of work between save and commit. 

 

The 'Save and commit' operation took 10 minutes for Leonie on Terminal 4. Note you don't see the spinning beach ball as the screen recording turns it into a normal cursor arrow. 

 

While this 'save and commit' was occurring. No one else can do any work.

 

We get the following alert  (operation failed) when we try to do anything. 
 

 

After the above 'Save and Commit' by Leonie, I 'refreshed' my file.

The refresh crashed the first time (after five minutes). The second time around was also 5 minutes, and did complete the refresh.

I took a screen video of this. Note the refresh icon, as that is the only indication of whether refresh was completed or not. 

 

 

I know the easiest way to deal with it is to discuss as some kind of user issue, and wish it will go away. We need a fix from you. We need a fix very quickly. I hope you can appreciate how much time I'm putting in here to screen record all the issues and report it to you. 

 

@Tolu I am DESPERATE for help. I'd do anything to be out of this situation now. Please help. 

[Amorphous - Julian 162]

[UPDATE 29/10/2019 @ 8pm]

 

We have finished another 3 hours of work. 

 

Leonie finished her work, then saved and committed. This is her video which took 10 minutes. 

 

 

After she finished her work, I 'refreshed' my file, which took 3.5 minutes. 

After the 'refresh', I did a 'save and commit', which took 5 minutes. 

 

This is all very slow. We can't all sit around waiting for files to Sync with these speeds. 

 

Edited October 29 by Amorphous - Julian

[Amorphous - Julian 162]

[UPDATE 4/11/2019]

We seem to be having some issues with Data Tags for:

- Doors

-Windows

- Walls

Some numbers in the Tags are showing on one user terminal but not others (inside the same viewport).

See screen shots. 

 

 

[Amorphous - Julian 162]

[UPDATE 4/11/2019]
We worked all day, and now faced again with the dreaded 'this file is corrupt' message again.

[KIvanov 24]

Hello Julian,

 

8 hours ago, Amorphous - Julian said:

We seem to be having some issues with Data Tags for:

- Doors

-Windows

- Walls

Some numbers in the Tags are showing on one user terminal but not others (inside the same viewport).

See screen shots. 

We have potential fix for this issue in SP2 of VW2020.

 

Best Regards,

Kostadin Ivanov

 

[Amorphous - Julian 162]

1 hour ago, KIvanov said:

Hello Julian,

 

We have potential fix for this issue in SP2 of VW2020.

 

Best Regards,

Kostadin Ivanov

 

wonderful- thanks Kostadin 

[Amorphous - Julian 162]

On 11/4/2019 at 11:22 PM, KIvanov said:

Hello Julian,

 

We have potential fix for this issue in SP2 of VW2020.

 

Best Regards,

Kostadin Ivanov

 

 

Hi Klvanov,

 

We had to revert to 2019 for above PS issues. 

 

In 2019- we have the same problem with some tags displaying text and others not (see screen shot)

 

Yesterday we issued a set of documents - which looks fine with text in tags.

 

But today we have to modify this document, and it will not show the relevant information. 

 

Unfortunately these drawings can't wait until version 2020 SP2. And that release would not help us in 2019 anyway. 

 

@Tolu sorry to bother, but would you be able to help on this issue too?

 

 

[KIvanov 24]

Hi Julian ,

 

The fix is only potential fix. If you can give us a test file with steps how to reproduce the issue, we will be able to test the fix.

 

Thanks,

Kostadin Ivanov