So the binary CAD data is not in files, it’s in some datatype in the DB, such as BLOG or something? That’s interesting, and perplexing.
For that to work with the “old fashioned” CAD systems that use files, the local PDM client would need to put the file together in cache from ONLY database records, not pull the file from archive server then set metadata (properties and refs) from the database like Solidworks PDM Pro does? Or am I confused on this?
I don’t know how SolidWorks PDM works, I was assuming it puts the CAD in the DB like other sophisticated PDM products do, but that sounds like it’s the wrong assumption. The defunct PDMWorks didn’t do that, in fact, it just used a big text file for meta data instead of a real database, and just renamed the actual CAD files. That was the main thing it was criticized for, and the reason it was so limited to small installations. I vaguely remember Conisio doing something odd with folders, so it’s entirely possible that they are storing CAD data in folders, the traditional non-PDM way. I’m pretty sure that the full-on Enovia doesn’t do that.
When I worked at a reseller ~2002 we auditioned Conisio, and I remember we chose to not carry it because of the sloppy way it dealt with the CAD file data. SmarTeam used a real db for all the data. Databases can handle a huge amount of data, especially since a lot of them were on Linux or Netware servers, not subject to Windows limitations.
My lay understanding of SW PDM Pro is that all the metadata and file refs and other stuff are stored in the SQL database, the files (all of the different versions) themselves are stored, usually on a different server, in archives. So the binary data that defines the model, assembly, or drawing is not stored in the DB. On the archive server there are in 16 folders named 0-F that contain subfolders with the versions of Vault files in those. The subfolders and file names use some naming scheme that I don’t know but it doesn’t matter because the archive server service handles that storing/naming/retrieving and uses the DB to keep track of the full path for each version of each file in the archives. The DB also keeps track of what folder(s) the file is in on the clients.
SWPDM uses a SQL Server back end for the vault database and stores the physical versions of the file on the archive server. Each client has a vault view location integrated with Windows File Explorer that is used as the local cache for working on files locally.
All file data including metadata, reference structures, BOMs, file locations, file versions, file status, replication status (for replicated vaults), etc is all stored in the vault database.
Have I said how happy I am that all our files are saved in File Explorer, with no PDM (generic or company name)?
Files on the archive are stored in those 16 folders (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). They represent the last digit in the document ID (Documents table) converted to hexadecimal.
So document id = ‘113579’ converts to ‘0001BBAB’, which is the folder it’s found in under the main folder ‘B’. All files inside are the versions and they are renamed to the version number. The DB knows where they are based on the DocID and downloads the file to the user’s cache in the stored folder location and renames it back to its original filename.
Here’s a site to do the conversion:
I think I know way more about this than is healthy 
“Archive server” meaning just straight CAD files? Are they at least renamed? Do users have a backdoor to access files on the “archive server”? This is marginally better than PDMWorks, but only by a little.
So what is real PDM in SW land these days? Enovia? SmarTeam?
Not just CAD files, every file that is in the vault goes on the archive server, PDM Stores any kind of file. It handles some better than others.
The file versions are renamed into some cryptic scheme. So if there’s file A.sldprt in the users’ vault view and it has 8 unique versions, then there will be 8 files in the archive server in some folder by some filename.
Only admins should have access to the archive server, they are not network shares. So no users cannot get to the archives. There is a tool for admins to use to find the archive file for a specific version of a specific file in the vault, or admin could find it in the DB tables manually.
I don’t know what Enovia is, I think it’s a cloud based PLM or ERP or some partial implementation of a bunch of acronyms. I think of it as a cloud based TeamCenter or Windchill, but someone can correct me on that.
Never heard of SmarTeam.
If a file has 8 versions, there may not be 8 physical copies of that file depending on which versions created a new physical version vs just updated metadata. To try to save on disk space, SWPDM does not create a new physical archive for a version that did not change the physical file. The archive also includes an index xml file that holds additional information about the files like which versions of the file uses which physical archive of the file.
For example, if you have a text file in the vault at version 2, then you check out the file and just update the data card for a variable that is not mapped to update in the physical file, SWPDM will create version 3 of the file on check in to store the new metadata, but the index file on the archive server will point to physical version 2 as the physical copy to use when a user requests version 3 of the file since the physical file of version 2 and 3 are identical.
Only admins should have access to the archive server, they are not network shares. So no users cannot get to the archives. There is a tool for admins to use to find the archive file for a specific version of a specific file in the vault, or admin could find it in the DB tables manually.
Access to the archive server should be treated just like any other sensitive server on the network. Physical access and remote access should be restricted to administrators who can be trusted. Basic users should not have any access to the archive server.
I did not know that it was the last hex digit in the docID that determined which folder they went into. I did notice that they were not evenly loaded (disk space), this would explain why.
Here’s an example. The file names are version numbers based in hexadecimal.
image.png
There is an xml that stores some version info. Not sure why they don’t use the DB for this, maybe data integrity as most of this info is in the DB. Notice version 4 and 9 have a reference to 3 and 8. This was a datacard only version change so they don’t copy the file and take up more space than needed.
Way better than than PDM/Works workgroup, which had no db and very limited functionality.
This is real PDM and is the primary application from SolidWorks. Smarteam is no longer sold. Enovia is 3dexperience rebranded. Of course Dassault would love everyone to go to 3dx but most companies don’t want or need it.
PDM, general term, has it’s places where it’s a necessary evil. In short, it was the reason we switched to Solidworks. If Solid Edge would have had a PDM (not TeamCenter PLM) we would still be using SE. We needed a couple things; specifically, version control and revision enforcement. Ironically, versions and revisions give me the most grief. 
Yeah, yeah, Solid Edge had a PDMish solution, it was based on Sharepoint, but when sharepoint community went away so did that solution leaving those user high and dry. They now have what’s called BiDM Built in Data Management, but it hinges on Windows File Indexing and is limited beyond that as well.
The archive folder is the hex converted DocumnetID number and is organized by the last number in the hex number.
You can also reverse the process of using the archive folder hex number converted into a decimal number to find the DocumentID for any file in the archive.
Ok, one more question. Does - let’s just call it Conisio - allow multiple “archive servers” as you are calling them? The marketing movies keep talking about multiple global locations, so this sounds like multiple “archive servers” for the managed data.
And then I’m assuming there is only one db, or a single db with multiple replicated instances.
SmarTeam, just for reference, uh, jeez. Just when I thought things couldn’t get more convoluted… it turns out that SmarTeam is now a brand under Enovia. So I’m going to guess that SmarTeam is the real PDM you can install locally on your own server, and Enovia is the cloud-based PDM. The DS site is saying SmarTeam is the small-medium company tool, while Enovia is for the big boys.
I went to training on SmarTeam on a yacht in Boston harbor back in 1997? I think. Is that right? Was that training or a party? Those days get a little blurry. Anyway, they were a small company. That’s where Joy Pineau came from. (“Who?” they all say?) Sigh. They developed into the main serious PDM for Solidworks, and one of the early Gold Partners. I guess they’ve been bought by DS.
It keeps the file extensions? Even PDMWorks didn’t do that. This is kind of lame, from an admin/security point of view. People got forced onto this after Workgroup (PDMW) went defunct? I remember hearing that nobody was really happy about that.
Anyway. Thanks for the info.
There must be another product that serious PDM customers moved to, I can’t see folks being too happy with this.
Yes, “Conisio” has the ability to setup multiple replicated archive servers to keep data “local” to offices in different physical locations. It allows for setting up automated replication of designated folders in the file vault but on demand replication will replicate any file to any archive server in the system if a specific file version is requested by a user.
And then I’m assuming there is only one db, or a single db with multiple replicated instances.
There is only one writeable DB. There is the ability to add read only replicated databases in multiple locations to help performance.
Hm.. didn’t realize SmartTeam was now an Enovia product.
I’m pretty sure that Enovia is the backend for the 3DS Platform stuff.
And sorry for the double post above. The site was telling me the post hadn’t worked so I tried it a second time.
Diaval thanks for the clarification, but that implementation is kind of a sloppy mess. They should at least remove or change the extensions. That is just a temptation or a target for people who get curious. It’s now coming back to me why we rejected Conisio.
I think you’re right about Enovia.
I took care of the double post.
No one but Administrators would be able to see that the archives use file extensions on the versions. I’m not sure it would be any more secure by removing the extensions. If a user has physical access to the archive server, i’m not sure that not having the file extension will slow them down much. That information is also in the index.xml file kept with the file versions.
I took care of the double post.
Thanks 
Here’s what our IT guy told me. Any product that requires only SQL Express uses the SQL database for indexing and stores the actual files in a folder (or folders). A higher license level of SQL (minimum of Standard) is needed for storing the files themselves inside of a database; at least if you have any appreciable amount of files. This is what differentiates the low-mid level PDMs from the higher level PDMs.
Solidworks PDM attempts to straddle this with PDM Standard and PDM Professional. Standard uses SQL Express and Pro uses SQL Standard. It’s another case-in-point of “you get what you pay for”.
EDIT: Here is a screenshot from Goengineer’s website.
2021-06-22 15_23_29.jpg
I just never like to tempt people. If they don’t know what it is, they might leave it alone. But if they think they know what it is, they might attempt a “rescue”. I did an implementation once that had some half-clever unbelievers, and they would try to get around the system any chance they had.
And then they might talk their IT buddy into giving them access… There’s always a way to screw up a fool-proof system.
Anyway, thanks for all the information.