PDM API why do file references rely on the "parentFolder" that the child file is found in?

[bnemec]

I'm trying to build a where used list of a file (to estimate impact of remodeling a few hundred pcs of hardware to assembly mates and drawing annotations) I have a list of the files to be remodeled from a sql query as getting it from PDM API calls would be much more difficult. My list is a list of DocIDs because that is how PDM tracks files, not by the path they are cached, right? I cannot get the IEdmReference11 object for my file without the folder it would be cached in if it were cached.

A bit of rambling back ground first:
I cannot make heads or tails of the way PDM does file refs or why Directories/Folders are called "Projects." There's this "parentFolder" or "parentFolderID" that shows up in some API functions.

For example, I can get an IEDmFile instance from vault.GetFileFromPath which will return the IEDmFile and pass out by reference the parentFolder object. Took my dense head a while to realize that "parentFolder" just means the folder that the file would be cached in. I think. Thing is it seems that I can call this even if that file is not in local cache, but I could be mistaken. Yes, File.Exists(filepath) would return false but I can still get the IEDmFile object.

Another example is vault.getObject(EdmObjectType.EdmObject_File, DocID). Say I have DocIDs from a SQL query and I'm going to work through them. I want an IEDmFile object so I use getObject and cast it. All well and good, until I need the darned "parentFolder" for the GetReferenceTree call. Which leads me to my question.

Why does file.GetReferenceTree(ParentFolder.ID) need a specific folder for the file I'm getting references for? I see the dbo.XRefs table tracks the "ProjectID" which == the parentFolderID. But why? I was told PDM doesn't care about folder structure other than to present the files to the user on their local drive. They are scattered in 16 directories on the archive server. So does this mean I can have one file (one DocID) that has different references based on which folder/directory/project it gets cached in? That sounds like a disaster!

Now, I'm looking at this from the perspective of getting the where used tree. If I look at from the db table I see the DocId column is for the parent which implies the table is laid out for parent to child relation. So if I look at if from the Contains/BOM perspective I get that the ref from parent to child needs to track which folder the child file will be cached so that PDM can update those in the parent file, if needed, when it's cached on client PC (even though Solidworks opens by file name and ignores the path given to it but I digress.) But why in the XRefs table? Isn't the caching location for all files kept in the DocumentsInProjects table? Is this redundant data? The query below returns an empty set indicating that at least in our vault the XRefProjectID is always == ProjectID from the DocumentsInProjects table.

Code: Select all

SELECT TOP (1000) x.[DocumentID]
      ,[RevNr]
      ,[XRefDocument]
      ,[XRefProjectID]
	  ,dip.ProjectID as dipProjectID

  FROM [CleanupVault].[dbo].[XRefs] as x
  join [CleanupVault].[dbo].[DocumentsInProjects] as dip on x.XRefDocument = dip.DocumentID
  where x.XRefProjectID <> dip.ProjectID

Sometimes trying to plan out an automation project without others to bounce questions off of l get myself into the weeds.

The solution I come up with is back on my query that gets the list of files to be remodeled add a join to the DocumentsInProjects and Projects table then concatenate (either in SQL or C#) the results to build the full path. Which seems so silly because I assume the GetFileFromPath(bsFilePath, out ppoRetParentFolder) will parse it back into pieces and use the Projects and DocsInProjects and Documents tables to find the DocID.

Can someone explain to me where I'm completely confused here or?

Thanks.

[JSculley]

Why does file.GetReferenceTree(ParentFolder.ID) need a specific folder for the file I'm getting references for?

I would guess that this is because a PDM file can be in more than one folder:

https://help.solidworks.com/2021/englis ... _files.htm

Of course, you aren't supposed to share files that have references, but the API can't know if that has happened so it is safer to require the parent folder ID.

[bnemec]

I would guess that this is because a PDM file can be in more than one folder:

https://help.solidworks.com/2021/englis ... _files.htm

Of course, you aren't supposed to share files that have references, but the API can't know if that has happened so it is safer to require the parent folder ID.

Oh, in that context the "parent" in parentFolder is talking about parent of the file being shared to another folder. If the parent folder is \A but then the file is shared to folders \B and \C and then someone uses the \B location in an assembly we want the reference to be to \A. That way we don't have any given file (DocumentID) referenced in more than one folder.

So every file has a parent folder whether it's shared or not. That does actually start to make sense now.