Page 1 of 1
File moved by mistake cannot be moved back
Posted: Wed May 11, 2022 8:17 pm
by mp3-250
I had a user that mistakenly moved a Solidworks file in the VAULT instead to copy it in a different folder.
The file cannot be moved back to its original folder as the
‘The file is referenced by a file that is checked out on another computer’ error cames up, with a list of supposed checked-out files.
Those files are not checked out at the moment or they even do not exist anymore (or probably they were renamed). I came to the conclusion that there are only ghost entry in the SQL database.
Wonder why this was not a problem when the file was moved by accident in the first place...
I have already looked up in the SW KB from the customer support portal and I found two solutions. S-019031 and S-077839 but I do not understand how to unlock the file.
From S-077839
Question:
If moving or renaming a file in a SOLIDWORKS® PDM file vault returns the error ‘The file is referenced by a file that is checked out on another computer’, how do I find which parent file to check in?
Answer:
When you move or rename a file inside a SOLIDWORKS® PDM file vault, none of the parent files that reference the file being moved or renamed are allowed to be checked out on other client systems.
This is because the move or rename operation updates the reference path in the database and in the physical parent files so that the referenced child file can be found in the new location or with the new file name.
Rename and move will also affect all versions of a file as the database only stores the current name and path, so the check applies to any parent file that has historically referenced the file being moved or renamed.
The move or rename operation becomes blocked and the following warning appears:
‘The file is referenced by a file that is checked out on another computer.’
To find the parent file that is blocking the move or rename, you can often view the ‘Where Used’ listing for the file failing to move or rename and see which parents need require check in.
Be aware that this applies not only to the direct parent, but also to any checked out parent file in any higher level of the file. For a visual reference, see the attached image ‘S-077839 Rename_Checked_Out_Parent_1.jpg’.
In some situations, the checked out parent file is an indirect parent, that is referenced from an in-context relationship or similar. In such cases, use of ‘Where Used’ does not display the parent file.
Effective with the release of SOLIDWORKS PDM 2020, the rename and move warning is more descriptive and shows the file name of the first parent document that is causing the operation to be blocked.
For a visual reference, see the attached image ‘S-077839 Rename_Checked_Out_Parent_2.jpg’.
To help identify all checked out parent files that block move or rename of a file, you can use the attached T-SQL report.
I run the SQL query and I got wich user and PC are supposed to have the referenced files checked out, but even some of those PCs and files do not exist anymore...
Any idea?
Re: File moved by mistake cannot be moved back
Posted: Wed May 11, 2022 11:43 pm
by jcapriotti
What version of PDM....I had this issue in earlier versions but 2020 fixed it and I was able to rename and move the files.
Re: File moved by mistake cannot be moved back
Posted: Wed May 11, 2022 11:55 pm
by mp3-250
We are using 2021 and SW 2021 SP5.1 on clients.
I suspect someone renamed the files while checking them out or some old PC was replaced without checking in the files, so it could be a remain of a vault view id that does not exist anymore...
Re: File moved by mistake cannot be moved back
Posted: Thu May 12, 2022 12:18 am
by jcapriotti
You can't see the checked out files to undo them?
Re: File moved by mistake cannot be moved back
Posted: Thu May 12, 2022 12:41 am
by mp3-250
No I cannot they are already checked in.
Three files are checked out for real, but three files are already checked in.
When I queried the SQL server the path of two files flagged as checked out was wrong (I compared it to the real path in the vault). I suspect those files were likely moved in a subfolder while checked out in the past.
One file is simply checked in and even looking at every sub assembly inside it everything is already checked in, so I cannot perform a check in or undo a check out.
Re: File moved by mistake cannot be moved back
Posted: Thu May 12, 2022 10:29 am
by jcapriotti
If you know which file is showing incorrectly checked out in the DB....you may be able to check it out for real....make a small data card change and check it in. That may correct the DB issue. If not, the DB itself needs correcting which I would work with your VAR.
Re: File moved by mistake cannot be moved back
Posted: Thu May 12, 2022 10:48 am
by AlexB
jcapriotti wrote: ↑Thu May 12, 2022 10:29 am
If you know which file is showing incorrectly checked out in the DB....you may be able to check it out for real....make a small data card change and check it in. That may correct the DB issue. If not, the DB itself needs correcting which I would work with your VAR.
I agree, direct DB editing can be very tricky, especially with the way the tables are interconnected. A VAR should be able to support this. And remember, DB backups are your friend in case you need to restore.
Re: File moved by mistake cannot be moved back
Posted: Thu May 12, 2022 8:07 pm
by mp3-250
I posted the issue here while I am waiting for my VAR reply. We ruled out DB direct editing as too risky (yes we have a daily backup, but with almost 100 seats and a lot of other issues I do not want to go down that way)
Some checked in files are already in an approved state and any version change is going to trigger a version update on their parent assemblies as well.
Re: File moved by mistake cannot be moved back
Posted: Fri May 13, 2022 6:32 am
by the_h4mmer
In some situations, the checked out parent file is an indirect parent, that is referenced from an in-context relationship or similar. In such cases, use of ‘Where Used’ does not display the parent file.
Is it possible that this is what's causing the error (from the KB text shared in OP)? It seems like it could point to why you're not finding the checked out file, since it's not listed and an indirect reference...
If an in-context reference isn't the issue, I wonder if it's possible to rename the file and then try moving it back? Was it moved using the Move Tree or just a cut and paste operation?
Re: File moved by mistake cannot be moved back
Posted: Fri May 13, 2022 10:10 am
by jcapriotti
the_h4mmer wrote: ↑Fri May 13, 2022 6:32 am
Is it possible that this is what's causing the error (from the KB text shared in OP)? It seems like it could point to why you're not finding the checked out file, since it's not listed and an indirect reference...
If an in-context reference isn't the issue, I wonder if it's possible to rename the file and then try moving it back? Was it moved using the Move Tree or just a cut and paste operation?
This is a DB error. PDM doesn't know about in-context refs except what it can record in the DB tables on check-in. If I had to guess, a checked out parent assembly file was deleted and one of the tables is out of sync with this information, thus the move of the child file is trying to update that deleted assembly and it see it as checked out. Whether it's checked out or not is stored in the "Documents" table. The deleted value is in several.
Re: File moved by mistake cannot be moved back
Posted: Fri May 13, 2022 10:13 am
by jcapriotti
@mp3-250
Try running this query and see if you get any results.
Code: Select all
--Query to list deleted files that incorrectly shows Deleted=0 in Documents table
--v2 - Handles deleted shared files correctly
--auxilliary temp table
CREATE TABLE #TempHistoryDelete( DocID INT )
CREATE TABLE #TempShareFile( DocID INT )
DECLARE @row INT
INSERT INTO #TempHistoryDelete (DocID) Select DISTINCT DocumentID
FROM HistoryDelete a
WHERE a.time = ( select max(time) from HistoryDelete b where a.DocumentID = b.DocumentID ) and Action = 1
--retreive all shared files
INSERT INTO #TempShareFile (DocID)
SELECT Hd.DocID
FROM documents d, #TempHistoryDelete Hd, HistoryShare hs, DocumentsInProjects dp, Projects p
WHERE Hd.DocID = Hs.DocumentId and dp.Deleted = 0 and d.DocumentID = dp.DocumentID and p.ProjectID = dp.ProjectID
--exclude shared files where one or more instances are still *not* actually deleted
DELETE FROM #TempHistoryDelete
WHERE DocID IN ( SELECT TS.DocID FROM #TempShareFile TS )
--List mismatched files
SELECT d.DocumentID, p.Path, d.Filename, d.Deleted
FROM documents d, DocumentsInProjects dp, Projects p
WHERE d.DocumentID IN( SELECT * FROM #TempHistoryDelete) and d.Deleted = 0
and d.DocumentID = dp.DocumentID and p.ProjectID = dp.ProjectID
ORDER BY p.Path
SET @row=@@rowcount
IF @row = 0
Select 'No mismatched records found' as [Result]
ELSE
Select CAST(@row as VARCHAR) + ' Mismatched records found - please run DeleteMismatch_Fix_v2.sql' as [Result]
GO
DROP TABLE #TempHistoryDelete
DROP TABLE #TempShareFile
GO
Re: File moved by mistake cannot be moved back
Posted: Fri May 13, 2022 11:28 am
by bnemec
mp3-250 wrote: ↑Thu May 12, 2022 12:41 am
No I cannot they are already checked in.
Three files are checked out for real, but three files are already checked in.
When I queried the SQL server the path of two files flagged as checked out was wrong (I compared it to the real path in the vault). I suspect those files were likely moved in a subfolder while checked out in the past.
One file is simply checked in and even looking at every sub assembly inside it everything is already checked in, so I cannot perform a check in or undo a check out.
This might be a stupid question, but I'm trying to follow along for exercise in trouble shooting. When you said you queried SQL for the paths of the two files, I'm assuming you were getting the full path (project table) by those Doc IDs, not file name? I've chased my tail over and over because I think of a file by it's full path but PDM knows a "file" by DocumentID.
In other words, does the DocID in the where used sql query match the DocID of the real path in the vault view? There's been times when PDM and I were talking about different DocIDs but same filename. And we don't have duplicate file names.
Re: File moved by mistake cannot be moved back
Posted: Sat May 14, 2022 12:30 pm
by the_h4mmer
jcapriotti wrote: ↑Fri May 13, 2022 10:10 am
This is a DB error. PDM doesn't know about in-context refs except what it can record in the DB tables on check-in. If I had to guess, a checked out parent assembly file was deleted and one of the tables is out of sync with this information, thus the move of the child file is trying to update that deleted assembly and it see it as checked out. Whether it's checked out or not is stored in the "Documents" table. The deleted value is in several.
Ah understood. Then I will move myself to the bench and watch from the sidelines, as this is an issue well beyond my experience! Best of luck and hope a solution is found/shared.
Re: File moved by mistake cannot be moved back
Posted: Sun May 15, 2022 8:37 pm
by mp3-250
bnemec wrote: ↑Fri May 13, 2022 11:28 am
This might be a stupid question, but I'm trying to follow along for exercise in trouble shooting. When you said you queried SQL for the paths of the two files, I'm assuming you were getting the full path (project table) by those Doc IDs, not file name? I've chased my tail over and over because I think of a file by it's full path but PDM knows a "file" by DocumentID.
In other words, does the DocID in the where used sql query match the DocID of the real path in the vault view? There's been times when PDM and I were talking about different DocIDs but same filename. And we don't have duplicate file names.
I am still new at PDM and I was put my role in a hurry, so I still have to attend the PDM administration course.
This said I have some experienced DB guy in my team and I have been working with this company PDM for about a year including design task, users training and troubleshooting.
Backon topic I used the SQL query below, attached to the KB Solution I quoted.
This query returned me six files hindering the move operation and their supposed path according to the DB.
three files are actually checked out, but three are supposed to be checked in. I wrongly assumed two files were deleted because when I looked inside their supposed folder I could not find them, but they were eventually moved in a sub-folder.
Code: Select all
----- Query to list checked out parent files that blocks move or rename of a specific file
----- Before running query, please update the QUERY PARAMETERS (row 94) below with filename and path to check
-----
-------------------- VALIDATION CHECKS BEGIN ---------------------------
------------- Verify that an EPDM database is selected
Declare @SelectedDatabaseName nvarchar(250)
Set @SelectedDatabaseName = (SELECT db_name())
IF OBJECT_ID ('SPU_UnlockFile', 'P') IS NULL
begin
RAISERROR( 'The selected database "%s" does not appear to be an SOLIDWORKS PDM database. Make sure you select correct database to run script on.', 16, 1, @SelectedDatabaseName )
Return
end
-------------------- VALIDATION CHECKS DONE ---------------------------
if exists (select 1 from sysobjects where id = object_id(N'[dbo].[SPRM_SubGetParentDocumentIds_SPR623463]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
set noexec on
go
CREATE PROCEDURE SPRM_SubGetParentDocumentIds_SPR623463
@iDocID INT,
@iterLimit int = 100
As
Begin
Create Table #oTbl (DocumentID INT, DocumentVersion INT, ParentDocID INT, ParentVersion INT);
Create Table #LevelOne_Docs (DocumentID int, DocumentVersion INT, ParentDocID int, ParentVersion INT);
Create Table #LevelOneResult_Docs (DocumentID int, DocumentVersion INT, ParentDocID int, ParentVersion INT);
INSERT INTO #LevelOne_Docs (DocumentID, DocumentVersion)
SELECT DocumentID, LatestRevisionNo
FROM dbo.Documents
WHERE DocumentID = @iDocID;
DECLARE @iter int = 1;
DECLARE @rc int = 1;
WHILE (@rc > 0 AND @iter <= @iterLimit)
BEGIN
INSERT INTO #LevelOneResult_Docs (DocumentID, DocumentVersion, ParentDocID, ParentVersion)
SELECT x1.DocumentID, x1.RevNr, x1.XRefDocument, x1.XRefRevNr
FROM XRefs x1 INNER JOIN
Documents d1 on x1.XRefDocument = d1.DocumentID AND
--x1.XRefRevNr = d1.LatestRevisionNo AND --SPR 700591 child files that going to be renamed might have different latest version number
x1.XrType <> 2 -- Should not be circular -- than parent latest version file.
WHERE x1.XRefDocument IN (SELECT DocumentID FROM #LevelOne_Docs)
set @rc = @@rowcount
IF (@rc > 0)
BEGIN
-- Copy the nodes from the OneLevel table to the aggregated table
INSERT INTO #oTbl (DocumentID, DocumentVersion, ParentDocID, ParentVersion)
SELECT DocumentID, DocumentVersion, ParentDocID, ParentVersion FROM #LevelOneResult_Docs
TRUNCATE TABLE #LevelOne_Docs
INSERT INTO #LevelOne_Docs (DocumentID, DocumentVersion, ParentDocID, ParentVersion)
SELECT l1r.DocumentID, L1R.DocumentVersion, l1r.ParentDocID, L1R.ParentVersion
From #LevelOneResult_Docs l1r LEFT JOIN
#oTbl pt On l1r.DocumentID = pt.ParentDocID --AND -- Only insert not previously found docs
--l1r.DocumentVersion = pt.ParentVersion -- since XrType only applies to the initially built chain --SPR 700591 child files that going to be renamed might have different latest version number
-- than parent latest version file.
WHERE pt.DocumentID Is Null
TRUNCATE TABLE #LevelOneResult_Docs
SET @iter = @iter+1;
END
END
SELECT DISTINCT DocumentID FROM #oTbl
End
GO
set noexec off
Go
DECLARE @SourceFilePath nvarchar(255)
DECLARE @SourceFilePathID int
DECLARE @SourceFileName nvarchar(255)
DECLARE @SourceFileNameID int
DECLARE @DestinationFilePathID int
----------UPDATE QUERY PARAMETERS-------------------------------------
--------------------------------------------------------------------------------------
--- *** Enter path and file name of the file that fails moving/renaming
--- Do not include the local view path and include the leading and trailing backslash character "\"
--- e.g. 'C:\MyLocalViews\VaultName\Folder\In\MyVault\' should be entered as '\Folder\In\MyVault\'
--- File name should include extension.
--- e.g. 'magnet.sldprt'
SET @SourceFileName=N'BS108 Oring.SLDPRT' --<File failing to move/rename. "File Name" column in warning dialog
SET @SourceFilePath=N'\Project\Gripper Assembly\' --<Path to file failing to move/rename. "Found In" column in warning dialog
--------------------------------------------------------------------------------------
--Check that file and folder inputs are valid
DECLARE @SourceFileNameCheckID int
DECLARE @SourceFilePathCheckID int
Set @SourceFileNameCheckID = (Select TOP 1 DocumentID from Documents where Filename = @SourceFileName)
if( @SourceFileNameCheckID IS NULL )
begin
RAISERROR( 'Could not find any file with the name "%s" in the vault database. Verify the name entered in the @SourceFileName parameter.', 16, 1, @SourceFileName )
Return
end
Set @SourceFilePathCheckID = (Select TOP 1 ProjectID from Projects where Path = @SourceFilePath)
if( @SourceFilePathCheckID IS NULL )
begin
RAISERROR( 'Could not find any folder path matching "%s" in the vault database. Verify the path entered in the @SourceFilePath parameter. Make sure it is relative to vault root and starts and ends with a backslash character "\"' , 16, 1, @SourceFilePath )
Return
end
--Checks done
Set @SourceFileNameID =
(SELECT Distinct TOP 1 D.DocumentID
FROM Documents D
INNER JOIN DocumentsInProjects DIP ON DIP.DocumentID=D.DocumentID
INNER JOIN Projects P ON P.ProjectID=DIP.ProjectID
WHERE Filename like @SourceFileName AND Path LIKE @SourceFilePath AND D.Deleted=0 ) --Matching on name and path
Set @SourceFilePathID =
(SELECT Distinct TOP 1 ProjectID
FROM Projects
WHERE Path = @SourceFilePath AND Deleted=0 )
Set @DestinationFilePathID = @SourceFilePathID
--(SELECT Distinct TOP 1 ProjectID
--FROM Projects
--WHERE Path = @DestinationFilePath AND Deleted=0 )
If (object_id(N'tempdb..#ParentDocID') Is Not Null) Drop Table #ParentDocID
If (object_id(N'tempdb..#MoveInput') Is Not Null) Drop Table #MoveInput
DECLARE @row INT
DECLARE @inputDocID INT; -- = (SELECT DocID FROM #MoveInput)
Create Table #MoveInput( DocID int, ProjID int, DestProjID int, NewName nvarchar(260) collate database_default )
CREATE TABLE #ParentDocID (DocumentID INT)
Insert into #MoveInput
Values (@SourceFileNameID, @SourceFilePathID, @DestinationFilePathID,'')
DECLARE InputDoc_Cursor CURSOR LOCAL FAST_FORWARD
FOR SELECT DocID FROM #MoveInput
OPEN InputDoc_Cursor
FETCH NEXT FROM InputDoc_Cursor INTO @inputDocID
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT INTO #ParentDocID
EXEC dbo.SPRM_SubGetParentDocumentIds_SPR623463 @inputDocID
FETCH NEXT FROM InputDoc_Cursor INTO @inputDocID
END
CLOSE InputDoc_Cursor
DEALLOCATE InputDoc_Cursor
Declare @ParentFiles Table (DocumentID int, Filename nvarchar(255), FilePath nvarchar(255), UserName nvarchar(255), LockDomain nvarchar(255))
Insert into @ParentFiles (DocumentID, Filename,FilePath, UserName, LockDomain)
Select distinct d.DocumentID,d.Filename,d.LockPath, U.Username, d.LockDomain from #ParentDocID pd join Documents d on pd.DocumentID = d.DocumentID Join Users U on d.UserID = U.UserID
where d.UserID != 1
--We need to insert info about all referenced files that prevent Move/rename of selected file(s) and keep track that this is valid references .
IF EXISTS (SELECT 1 FROM @ParentFiles)
-- Insert Into
--#Errors
Select distinct
pf.Filename,
mi.DocID,
pf.FilePath,
pf.UserName as [Checked out by],
pf.LockDomain as [Checked out on]
--mi.ProjID,
--mi.DestProjID,
--9, --9=Moerr_ParentLockedElsewhere
--pf.DocumentID
From
#MoveInput mi,
Documents d,
@ParentFiles pf,
XRefs x
Where
mi.DocID <> 0 and
x.DocumentID = pf.DocumentID and
d.DocumentID = mi.DocID and
exists
(
Select 1 From
Documents d1
Join #ParentDocID f on f.DocumentID = d1.DocumentID
Where
d1.Deleted = 0 and
d1.LockProject <> 2 --and
-- d1.LockViewID <> @ViewID
)
SET @row=@@rowcount
IF @row = 0
Begin
Select 'No checked out parents found for: ' + @SourceFilePath + @SourceFileName as [Result]
End
Re: File moved by mistake cannot be moved back
Posted: Thu May 19, 2022 7:34 pm
by mp3-250
In the end the issue was simple: only the checked out files was the reason we could not move back the file.
The other files listed in the warning in a locked status were apparently not affecting the move operation itself.
The vault rights to move a file around seems to supersede the status of the file. i.e. In principle a locked file child should not be moved around the vault, but if the file/folder rights allow it the locked parent file will be listed in the warning even if it does not affect the possibility to move its child.
The erroneus path and the wrong check in status I got from the query are probably unrelated issues we have with our DB apparently. Still need to investigate further.