Hi,
We have the vault program setup on a Windows 2000 / SQL 2000 SP3 Server. All of our clients are identically configured with Windows XP Pro SP1 and Vault 2.0.1.
Now the problem is that on 3 of our clients it all works fine, but on 2 of them the project tree is duplicated:
$/foldera/
$/foldera/
$/folderb/
$/folderb/
etc.
The clients who have this duplicating effect can still use the program just fine it seems, just the annoyance of having duplicates to sort through.
Has this happened to anybody else? How can we fix it?
FYI: I have tried restarting IIS on the server, restarting the clients PCs, etc but it still happens.
Chris.
Vault 2.0.1 - Duplicating files in tree view on some clients
Moderator: SourceGear
It sounds like the client-side cache files are corrupt. You should try deleting them as described at http://support.sourcegear.com/viewtopic.php?t=6
I'm guessing that there was a DB restore at some point?
I'm guessing that there was a DB restore at some point?
-
Guest
OK, deleting that folder got rid of the duplicates, but now we are trying to share a folder and the following is logged:
Violation of PRIMARY KEY constraint 'pk_tblfsobjectshares'. Cannot insert duplicate key in object 'tblfsobjectshares'.
There have been no restores of the database at all.
We can still share other files, this error only happens on a folder that the person who was seeing the duplicate folders shared while he had duplicate folders showing and then deleted the shared folder.
When he had the duplicate folders and then shared a folder it did this:
So he deleted the share and then deleted the cache. But now we can't redo the share of "filefolder" on any PC. (for now we have worked on the fact that all other files are still shareable, so we created a new "filefolder" under the "someotherfolder" and shared the files underneath it instead)
Of course we are just wondering if this could be a serious problem and we should restore last nights backup?
Violation of PRIMARY KEY constraint 'pk_tblfsobjectshares'. Cannot insert duplicate key in object 'tblfsobjectshares'.
There have been no restores of the database at all.
We can still share other files, this error only happens on a folder that the person who was seeing the duplicate folders shared while he had duplicate folders showing and then deleted the shared folder.
When he had the duplicate folders and then shared a folder it did this:
Code: Select all
-- before sharing filefolder --
$/foldera/
somefolder/filefolder/
someotherfolder/
$/foldera/
somefolder/filefolder/
someotherfolder/
-- after sharing filefolder --
$/foldera/
somefolder/filefolder/ <--shared from here
someotherfolder/ <-- share didn't appear here
$/foldera/
somefolder/filefolder/ <-- this folder didn't show the "shared" icon
someotherfolder/filefolder/ <-- share appeared here
Of course we are just wondering if this could be a serious problem and we should restore last nights backup?
I would suggest rebooting your server, as the confused clients may have confused the server as well. I'm very interested in how your set got to be in this state. Did anything odd happen to these folders? Were the deleted/undeleted, pinned, security rights applied to them, anything at all?
To correct the problem of the primary key violation, I would recommend trying to branch the one link that is still visible and share that branch to the other desired location.
To correct the problem of the primary key violation, I would recommend trying to branch the one link that is still visible and share that branch to the other desired location.
-
Chris
The only wierd thing I suppose that happened to the client machine was that it crashed last week. But apart from that nothing.
On the primary key violation, the folder is working now since we shared the files inside it, and all other sharing operations seem to work fine. I assume that Vault uses a combination of the file id and the path to create the primary key in the shares table? If that is the case the issue shouldn't affect future shares should it?
Chris.
On the primary key violation, the folder is working now since we shared the files inside it, and all other sharing operations seem to work fine. I assume that Vault uses a combination of the file id and the path to create the primary key in the shares table? If that is the case the issue shouldn't affect future shares should it?
Chris.