Jump to content
  • 1

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


Amorphous - Julian

Question

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 by Amorphous - Julian
Changed the title to reflect the evolving project sharing issues.
Link to comment

Recommended Posts

  • 1

[Update 2 19/03/2020]

 

So, we needed to find out what the above 'corruption' means for us. And it has left me very upset.  

 

🤬🤬🤬🤬This is a ridiculous, bad practical joke. It is wasting our Professional time!!!  🤬🤬🤬🤬

 

PROJECT SHARING DATA LOSS IS A SEVERE ISSUE!!!! KINDLY SOME FROM VECTORWORKS ACKNOWLEDGE THIS

 

This is what happened after the latest 'This File is Corrupt' (as above post) and after all users 'S&C':


(1) All Titleblocks from the file has disappeared from Computer Terminal 2 (CT2) and Computer Terminal 3 (CT3)

(2) Computer Terminal 1 (CT1) doesn't get the changes to viewports committed by CT2 and CT3

(3) New viewports created by CT2 and CT3 do not show up on CT1

(4) Annotations in certain viewports (annotations created well before today) disappeared from the viewports when viewed on CT1
(5) Annotations that has disappeared when viewed on CT1 is still present on CT2, but not on CT3

(6) Annotations that has disappeared when viewed on CT2 is still present on CT1, but not on CT3 ... etc

IN OTHER WORDS, PROJECT SHARING DATA LOSS IS A DAMED MESS!

This is what we have to do to untangle this mess (and not the first time we've gone through this process):

(A) Conduct data loss forensics (as above) to see who has lost what
(B) Create a 'new version' based on the file with least data loss, or with data loss that can be more easily replaced by 'copy and paste' operation, with data from older file.
(C) In this case, the file with the most intact titleblock is the one we choose to base the new version on, as it is an almost impossible task to copy over 300 sheets worth of titleblocks from one file to another for the working files that have lost their titleblocks. 
(D) We had to re-create a lot of the viewports that was done this morning. As these new viewports did not show up on the CT1 version, which the new version was based on. 
(E) We have to copy-and-paste viewport information that has been lost from older files. 

(F) Right now, we do not have the time to check through every sheet and every viewport to see what was lost, so, we may end up with some data losses in viewport that later causes us legal issues. (remember, drawings are legal documentation, if we issue drawings that has omissions, we are legally responsible- and guess who caused that?)

 

image.thumb.png.89be7416d33035bdd3b2bd69361e072d.pngimage.thumb.png.9036f765c73d9b71df366c1c0759e667.png

image.thumb.png.4851277ac4fa60ddbc7123b72d2b189d.png

image.thumb.png.ee239e182af8dc47441c91fe1be6b0d6.png

 

@Julian Carr @Biplab @Tolu This is beyond ridiculous. I am an architect, NOT a data forensic person. I shouldn't have to do this on a weekly basis. This is happening way too often!

File-based project sharing doesn't work. Other softwares have gone down this path and proven it. When will this change?

I am left asking myself: 

- What is the economic loss from all my issues since September 2019 (and earlier) caused by Project Sharing issue? I can tell you based on our charge-out rates it is pretty hefty 

- How would it feel when I receive my 2021 VSS subscription invoice, given everything I have gone through and documented here. 

 

Link to comment
  • 0

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?

 

Link to comment
  • 0

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. 

1.310_B.png

1.310_A.png

4.001_B.png

4.001 A.png

Link to comment
  • 0

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

 

image.thumb.png.acb7f4a33e790e6f96b74a94bba775bb.pngcid:B454F562-F8D1-45D0-9035-66586585A3BF

Link to comment
  • 0

[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:

image.thumb.png.65d1a78f1e1e7471a240109b7241ee09.png

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

 

image.thumb.png.cdc7c4ad77c2f5db41680a0621d1df53.png

Link to comment
  • 0
  • Vectorworks, Inc Employee

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:

image.thumb.png.65d1a78f1e1e7471a240109b7241ee09.png

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=

 

Link to comment
  • 0

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

29576825-B50B-45A3-B5B6-4F95D33B6B25.jpeg

Edited by Amorphous - Julian
Link to comment
  • 0
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.

Link to comment
  • 0
  • Vectorworks, Inc Employee
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.

Link to comment
  • 0
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

Link to comment
  • 0
  • Vectorworks, Inc Employee

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. 

Link to comment
  • 0

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. 

Link to comment
  • 0

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


image.thumb.png.c1f4228de907c7446cf8351ac8096310.png

 

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. 

Link to comment
  • 0

[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 by Amorphous - Julian
Link to comment
  • 0
  • Vectorworks, Inc Employee

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

 

  • Like 1
Link to comment
  • 0
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?

 

 image.thumb.png.8cce3e29ebe0b0fcccc6047e7c16b27f.png

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