Project Sharing Crashing When Committing, Refreshing and Releasing

[Seth Thomas]

I am running Mac OS 10.10.5 on Mac Pro 2 x 2.4 GHz Quad-Core Intel Xeon. I administer a group that uses VW2016 on both Mac and Windows platforms. We work from a server using Project Sharing. The project file is kept on the server. I store my project file on my local machine, but others store theirs on the server. The issues described below do not seem to care where the project file is stored, nor which OS is being used. We all experience the same issues.

I've been experiencing occasional crashes when committing or refreshing, seemingly at random times. Upon reopening VW after the crash I find that layers that were checked out before crash are now still checked out, but VW thinks they're checked out by another user, even though they're checked out by me. It seems to forget who I am and won't let go of the layer without a fight. When trying to commit the changes made before the crash, I get errors stating that there are conflicts with the other user (me) and asks if I would like to keep my changes or the other me's changes. No matter which option I chose, I get to the end of the process and the program crashes. The same happens when trying to refresh, save and commit, or close and release. If I force release the layers through the Project Sharing menu, I do not get a crash. Using this method I sometimes lose the last set of changes (as if the changes were committed before the crash occurred and VW just doesn't realize it), sometimes not (as if the crash happened before the commitment).

Fortunately, normal saves of the working file work fine, so the habit I have gotten into in lieu of a fix from VW is to save a copy of my project file as a regular VW document for a safety (so I can copy in any lost changes if necessary), then experiment with various possible solutions. I have yet to find one except to force release layers and hope that the changes have committed. After this, things seem fine until it happens again a day or two later. Another way is to create a new project file from my working file, but this only works if other users have committed all their changes and my file is refreshed before creating the new project file. I also commit as often as possible, being aware of any other users committing at the same time, which causes problems too.

Also, after all the above occurs, I find one or more .vwxp files of the project file, so it seems like this may somehow be related to the autosave function of the project file. I've disabled this function for a while to see if this helps.

Clearly, this is not an acceptable way to work. Does anyone have any insight into this? Will VW be addressing this is the next Service Pack?

[PVA - Admin]

This isn't something we are seeing broadly, no. Make sure to contact technical support directly about this and have the files ready to submit to them for troubleshooting. There are just so many variable when it comes to Project Sharing in particular compared to other types of questions that I wouldn't even be able to start troubleshooting reliably here.

There are many Project Sharing related fixes going into the next SPs, but from what you've posted above I couldn't guarantee your specific issues would be resolved.

[TimG]

We have similar issues with crashing almost identical to the scenario you describe (with server/local files and mixed OS's) , but more annoying than the crashing is the locking oneself out, which is also pain in the rear to rectify. One thing to note is I turn off the autosave off and it still happens to me/us.

I've also noticed if I check out too much and not save and commit directly afterwards or before its more likely to crash every save and commit the further down the line I get from the vwxp file on the server... case in point I go to issue manager to update global date of all my sheets, which requires me to checkout all sheets with that field in their title block... Before I attempt this I save and committ and release everything I've done so far... then I do it, it prompts and I accept to check out all the sheet... but if I don't committ all those sheet layers directly after that change I'll have a hell of a time trying to get the file to commit without crashing if continue working on something else.

guess I'm saying I notice these issue too and hope its debugged and addressed soon... If I come across it again in the office I'll try totake some extra time and submit it for tech support

Edited January 20, 2016 by TimG

[PVA - Admin]

Please make sure you've gone over this extensively with tech support directly, the issues so far have had similar symptoms but no single cause, so unless you've gotten support to confirm and file a bug, a fix may never come for your specific issue.

[Seth Thomas]

Thanks TimG for letting me know that I'm not alone out here. Your issue sounds just like ours. I also disabled auto save for the project file and that did not solve the problem.

I'll be talking to tech support very soon.

Edited January 28, 2016 by Seth Thomas

[Tom Klaber]

Seth / Tim,

Let us know if there has been a resolution. We are about to implement Project Sharing here and would greatly appreciate any pre-troubleshooting we can get.

[Jonathan RD]

We're having the exact same problem as Seth and Tim is pointing out.. apparently our crashes seems to be trigged when we're two person attempting to commit / check-out our projects at the same time, or too close to one-another - Or when one user is checking out a layer and another one is committing. So far it seems that it can be a random layer being checked out, when committing a specify layer.. But the user committing is more offen the part crashing..

The user with the crash is locked out of his/her layer, and is forced to lose the latest work.. Another annoy thing about this, is the continues crashing when the user tries to discard his/her changes, when refreshing / committing after a crash. This usual resultats in the need to create a new working file from our project-file, which has resulted in a couple of corrupted project-files and two instant where the project-file was randomly move to trash?..

We've been working with project sharing since the day it was released, hoping the first update, where the "waiting / Project-file is in use" error was implemented.. This only cut our crashes in half, but doesn't fix the problem..

[Drake]

I am experiencing the same issue. The message I get when I try to commit reads -in part- "The Administrator revoked your exclusive lock on that layer, and other users have subsequently committed changes on that layer. If you you choose to continue, your uncommitted changes o that layer will be lost." I am inclined to attribute this to crashes.

We have two users using the project file, both are administrators and all files are on the server.

I have nothing to offer, except another voice sharing the same concerns.

[PVA - Admin]

I am experiencing the same issue. The message I get when I try to commit reads -in part- "The Administrator revoked your exclusive lock on that layer, and other users have subsequently committed changes on that layer. If you you choose to continue, your uncommitted changes o that layer will be lost." I am inclined to attribute this to crashes.

We have two users using the project file, both are administrators and all files are on the server.

I have nothing to offer, except another voice sharing the same concerns.

What were the suggestions from Tech support in your case?

[ida]

Hi,

We have had a similar issue.

One of the users (we are 3 on the project) have had issues the last week with files crashing.

It happens when she tries to commit both with save and commit or through the project sharing menu.

In the last instance she has one layer and one sheet checked out.

We did a new working file from the project file and the changes that she had committed when the old file crashed was luckily there.

Just had to forced release the sheet that was looked through the old file.

When trying to commit again it worked.

So a happy ending on this one.

We have the project file on the server and the working files locally.

It has been sent as a problem to our vectorworks guy as a problem.

Ida

[ida]

Hi,

It also seems to be an issue if you have a lot of sheets and layers checked out.

It crashes more often if that is the case.

It can be solved by using the project sharing menu, but it seems there is a bug whit it.

Some times randomly when you chose one or two layers to check out and you have several checked out. It checks out all of them even if you have not chosen all of the,.

Ida

[nrkuhl]

I've had some similar experiences, and here are my thoughts so far (have not been able to reproduce anything on command, haven't submitted any reports yet other than the automated Mac crash report). We are an all Apple office, all project files are on a server, working files are sometimes local, sometimes on server (I've been experimenting to see what seems better for both ease of use and performance).

1. If you experience one of the random crashes that seem to be a symptom of 2016, while working in a project sharing working file, some or all of the symptoms described in the OP will happen (VW forgetting layer checkouts). Typically, I've been able to open a working file autosave backup, force release the checked out layers (even though they're checked out to me, I don't have control of them through the backup), and then commit changes. I have not had issues with crashes while doing this on my machine.

2. I came in this morning and my boss's VW was crashing on Close/Release operations. It was also disassociating layers from his user, so when a new working file was opened, his old layers were shown as checked out by another user. I force released, deleted his old working file, created a new one and everything seemed to work fine.

Where this gets particularly annoying is that in creating a new working file, our database related worksheets get all messed up again (which I have previously bug submitted and talked about here), so I had to re-import them.

Back the original topic, the major differences that I see between my boss's working habits and mine are that he works off a laptop that sometimes goes home with him (in which case he accesses our server via the appleshare protocol), and that he is really bad about leaving files open when he leaves for the day, even if he's committed changes. This results in his computer going to sleep with working files open. I'm working on training him out of the latter, but there's not much I can (or want) to do about the former. I would not be surprised to learn that either case causes problems with Project Sharing, even though working through the appleshare protocol (which basically seems to be a vpn?) shouldn't.

[PVA - Admin]

For anyone still experiencing this, I cannot recommend strongly enough that you increase your error reporting setting to the maximum level, then restart Vectorworks as described here:

http://kbase.vectorworks.net/questions/1380/Error+Reporting+and+Detailed+User+Logs

These detailed logs will significantly increase our ability to detect and correct the source of these types of issues.

[cwilliams]

We had the same issue as everyone is describing today, or at least is sound like it. I sent in the error report when it crashed and I just sent the file in using the support request form. The one thing we are having problems with is there isn't a lot out there about using the Project Sharing. I have watched the videos on YouTube but that isn't enough information. Is there some place where we can learn more about the in's and out's of Project Sharing?

Christinia

[PVA - Admin]

Currently the main issues we are seeing are with mixed OS environments or Mac-only environments. Apparently the issues that Apple has been having with AFP/SMB and SMB2 since around Mavericks are causing us extreme problems, since the large majority of our userbase is based on Mac or works in an office with both Mac and Windows hardware.

Unfortunately, because of the nature of the problem, there aren't any workarounds available other than "Windows clients and Windows servers only" but that's no good as a solution.

Very little of the crashing we are seeing is related to anything done incorrectly on the user end other than the occasional user trying to use a dropbox folder as their server location, which we advise against. I wish I had better news to share, but we are still working on getting around this completely. Tech Support has a number of meetings lined up with the engineers in charge of Project Sharing in order to address the biggest concerns, which include frequent crashing.

[Seth Thomas]

This thread has exploded a bit since my initial post and I'm just catching up. Since then I have been in touch with Tech Support, sending crash reports and trouble shooting. We agree that the issue may be related to autosaving. Last report was that the issue was sent to the engineering team to be worked on for the next service pack. I'll report back when I hear more.

[mdarch]

we get this error sporadically too when trying to save and commit - "The Administrator revoked your exclusive lock on that layer, and other users have subsequently committed changes on that layer. If you choose to continue, your uncommitted changes to that layer will be lost."

The only work around that works for us is to save a copy as a vwx file, then quit the file, re-open it and choose revert. Then open the vwx file and copy and paste the changes back into the reverted project file

The project sharing has been working much better since SP2

Mike

VWA 2016 SP2 / Win 10 / i7-4790 @ 3.6 GHz / 16 GB RAM / GeForce GTX 970

[ottoLejeune]

After many crashes... project files disappearing... lots of lost time... we have stopped using 2016 Project Sharing until it can be proven to be more reliable.

SP3 seems to have fixed a number of issues... but the AFP/SMB issue that plagues the Project sharing feature is not worth delving into that again.

The guide for VW project sharing says we need to connect our Macs to our Mac server via AFP and not SMB. But SMB is the default since 2014. It's not a simple matter to try and force all the Mac's in the office to revert back to the old AFP format. (Believe me, we have tried!).

I look forward to the VW team to come up with a solution that can make this Project Sharing feature "just work". Right now, it does not, "just work".

Unfortunately, I suspect they are busy stitching up their 2017 "features", planning 2018 features...etc. instead of focusing on simply making a version that "just works". That's just my feeling.... what with them having to push out a new version every year... which doesn't seem to "just work" until at least SP 3 or 4.

Will try again when SP 4 comes out the door.

[Seth Thomas]

Since the SP3 update I have been using Project Sharing to share with myself. That is, I have a Working File on a MacBook Pro that I use to work from home, and another on a Mac Pro that I use at the office. These both sync to the Project File on our server, which I connect to using the SMB protocol. Our IT department tells me we should be using AFP for our Macs, but that doesn't work and SMB always does. This is a small scale test before I try again with the whole department across Mac and Windows platforms in the fall.

What I can report so far is that everything seems to be working 'fine'. I put fine in quotes because what I really mean is that VW is operating in the manner that I've come to expect, which is far from totally stable, but usually good enough, and in some ways quite nice. Project Sharing has caused no problems, and I've even had the files crash in the middle of a commit process, re-opened the file, and completed the commit with no problems or data loss. Prior to SP3 that would have been a disaster. So this is a positive report. More to come when we expand to other platforms.

As a side note, I have noticed that, in general, VW does not like to be connected to a server while working, no matter how fast the network (though, the faster the network, the better). Working from the office is much more stable than at home because of the super-fast network, but simply being connected to a server causes slow-downs that don't happen at all while working offline. This is VERY noticeable using a VPN via my residential connection. It is protocol (though not a rule) in the office to maintain a connection to the server at all times. I think that many VW instabilities that I assumed were due to quirky programming may actually be because of this (though that's a programming issue in its own right). I'm going to try disconnecting from the server and working mainly in offline mode for a while, connecting only to sync, and see how that feels.

[nrkuhl]

Thanks for updating Seth.

It seems like I'm going to need to push to switch everything to SMB in the office, which means we'll need to set up a different VPN system for my boss when he works remotely (he uses AFP now, which seems to function as both VPN and local network file sharing, I'm historically a windows guy, so this mess is all new to me).

We are also a server based office - I'm interested to hear the results of your offline experiment. Also, to clarify, do you always keep your working files on your local machine?

We have a long standing practice of keeping everything on the server - standard files, project sharing files, and even working files. I experimented a while back to see if I noticed a performance difference between local and remote working files, and didn't, but I didn't carry the experiment on long enough to see about long-term stability issues. Did the local working file improve stability over AFP, or just in conjunction with the SMB switch?

[zoomer]

Since the SP3 update I have been using Project Sharing to share with myself.

^ That is cool :cool:

[Seth Thomas]

AFP is superior for an all Mac environment, and I would use it if I could, but SMB just works for us while AFP doesn't, so that's what I'm going with. This may be an issue specific to our setup, so be careful making any changes to your system based on my report. Our IT team isn't really on top of things, so I make it work any way I can.

I keep my working files on my local machines and encourage others to do so also. While it's not strictly necessary, it does seem to provide a slight performance enhancement. SMB vs AFP did not seem to be a factor in this case. The other major reason for keeping the working file local is that I can work offline from home. In this case I do all my work offline and only connect through a VPN to sync to the project file. Working in online mode introduces tons of slow downs, but offline is no problem at all.

[Seth Thomas]

Quick update:

I've been project sharing with another drafter on my latest project and so far so good. I've even had a crash during the commit process, reopened the file, recommitted and no problems. It just picked up from where it left off. I'll report if I encounter problems, but it looks like SP3 may have been the fix.

I am noticing one other (fairly minor) issue now regarding sheet borders, but that's for another discussion that I will post soon.

[gester]

On 7.05.2016 at 0:04 AM, zoomer said:

^ That is cool :cool:

i was wondering how did you come on those almost 3k posts within 2.5 yrs, but it's the proof: you put everywhere your 2c, even when you don't really have much to say

no offence, though  your pluses are probably justified...

[kufuffin]

On 1/20/2016 at 0:26 PM, Seth Thomas said:

so the habit I have gotten into in lieu of a fix from VW is to save a copy of my project file as a regular VW document for a safety

Hi, how does one convert a working file back to a regular file?  I tried saving a copy, but it opens like a working file.  Thank you

Edited January 24, 2017 by kufuffin