File DUPLICATION in PDM how to merge

Hello 

I'm in the middle of a spring cleaning that has been going on for a few months...

Following the implementation of a PDM in the company I have just joined, the service provider whose name I will not mention (A... O) to launch a copy of the windows server database, and by unfortunate manipulation to duplicate this database in PDM partially then totally then not archived etc etc = > result, I have identical files everywhere in the trunk (toolboxes, screws, commercial elements etc ....)

I would have liked to know if any of you have a solution for creating a listing under pdm grouping together duplicate filenames and the access paths of those in order to launch a hypothetical renaming task which will eventually result in a file deletion.

I have PDMtools and cadtools ;)

 

Thank you in advance

Hello 

Are all the duplicates locally on your computer or on your server? 

There are software like CCleaner that removes or lists duplicates in a chosen folder. 

On the other hand, strange that the pdm is accepted, duplicates in the trunk. 

Hello Haderack,

As I said it's on the PDM server, so no possibility to use a software like ccleaner.

The PDM fully accepts duplicates when the installer does not activate the rule prohibiting duplicates. But be careful because this rule is a trap in itself because it only prevents the archiving of files not their saving on the local view. The positive point of this rule is that it prevents you from duplicating for example a screw when using the PDM tree copy.

 

 

Hello

For my part, not having the PDMTools and CADTools tools (so I can't say what they can do), I use macros in Excel to query the vault and do processing.

@Cyril.f, yes it's an idea, but direct in request to the SQL?

Hello

Look at the EPDM Report Generator, see HERE.

Kind regards

@dD.Roger, fine for variables, or which files are extracted by whom, but not for duplicate parts.

On the other hand, yes, I can already find the toolbox parts thanks to this! 

The query you are interested in is not part of the standard EPDM queries, so you have to create your own SQL query in a crp file and import it into the tool. However, as stated in point 5, "These queries can be created by experienced administrators. However, one must have a good knowledge of the SQL language and the structure of the database." otherwise refrain and ask your dealer to create it.

Kind regards

Otherwise, you can also through the EPDM search tool, create a search on all the files in your vault and then export the result in a csv file, then you have to play Excel to sort all this. Be careful, depending on the number of files present, the search can last (very) long and the result may exceed the number of lines accepted by Excel.

Kind regards

My previous experience as a CAD admin allows me to do a lot of things via the administration interface, but for SQL, even if I already have some elements under my belt I remain cautious on the subject....  

I tried with the PDM search tool but I'll have to modify a few points to be a little more precise.

Cdlt

1 Like

No, it's client-side database processing. Touching the server or the SQL database is rather dangerous on Solidworks PDM as far as I know (question of stability of the database).

The archive server stores in a hexadecimal format the physical files, which are themselves saved in these folders, are also named with a hexadecimal name corresponding to the version number (for example, version 1 of a file will be named 0000001.SLDPRT).

Then links are made between this hexadecimal tree and the SQL database. From memory, by completely deleting a file on the client side, the server empties the folder containing the files and maintains the folder to avoid inconsistencies.

1 Like

@Cyril.f, yes I prefer to use the SQL search tool as a last resort,

or as I had created in another life, a weekly report of people who had extracted files more than X Days without archive.=> but not very effective due to the complexity for a BE of + 20 people

 

@Cyril.f,

I don't understand the "No"? Whether it's the report builder or the search tool, these are used on the client side, the report builder queries must be written by people who are familiar with their subject as stipulated but these queries only read SQL databases.

Kind regards

@d.roger, I replied about my use of macros that are not based on SQL queries. I don't question the fact of running queries to query the SQL database.

 

Following the submission of a ticket on the subject, it is necessary to go through an SQL requette, to have all the information

in report generator we do 

--Searching for duplicate files in the vault
SELECT [Filename] FROM [dbo]. [Documents] GROUP BY [Filename] HAVING COUNT(*) > 1

in a CRP to just have a list of duplicate filenames (without the quantity)

-----

Advantage of doing it via SQL directly, you can combine several searches... but now I have to study first....