Database Merge

Hello, following a takeover of companies and with a view to a merger of general services, such as design offices, here 3 design offices in a very similar sector of activity with different products but all under solidworks including a design office under PDM... How to apprehend and envisage a merger of BDDs? Is it relevant to merge while starting again on a common basis with the problems that it will bring? Divide each database on a dedicated server? What are the questions to ask yourself, have you ever experienced this kind of operation?

In addition, you probably don't have the same way of naming parts and assemblies, which must not help things.
Risk of duplication also on the screws side for example (different names but same product) or any other parts of the trade, cylinders, engine, and other joys. :grin:

Good luck grouping all this.

3 Likes

Above all, don't rush, in the 1st time don't change anything!
Analyze the 3 ways of working well (try each of the 3 methods), to name the library rooms... Pump the best of the 3 ways and design a perfect new one, to be tested and then applied, if validated, for all future new designs if possible.
To pass it all keep as it is.
Or else you all switch to Autocad or Topsolid so no jealousy!:joy:

3 Likes

1 - As @sbadenis says, wait
2 - is the PDM kept (I guess so);
3 - Are there duplicate products?

As for libraries, there is no choice, we will have to make do with the history. So keep the 3 in the archives (to be able to open the old studies) and define a single one for updates and new designs.

In terms of products, keep the 3 in archives and import those that are used as they go. This will allow a natural purge of obsolete studies.

Good luck

2 Likes

Like the colleagues above: it is urgent to wait.

I have a few companies to my credit, ranging from small SMEs (3 people) to large groups (several global sites) or even groups with different companies.

It appears that it is very rare to merge all databases. On the one hand because of the history, on the other hand because the common parts are not often proven and finally ... because we have to think about the future!
What will happen when one of the companies is sold? How would you easily separate the files that belong to it from yours?
Another question to ask yourself: are there any documents intended for the defense and/or confidential? In which case, customers will not want the plans to be propagated to the entire group

There is surely a rationalization of costs to be done by having a single physical server for example, or by sharing Sldw licenses. But keeping a "virtual" separation in the PDM, and therefore your files, way of codifying etc., seems to me to be beneficial.

2 Likes

Hello

I agree with @coin37coin and that's what we've done so far on the Solidworks PDM side. Each entity that uses PDM has its own vault, we only share the SW license server.

Hello

In our case, we were very happy to have 2 separate bases when our company sold us.
A common database would surely have generated strong complications (who gets which file??).

WARNING: PDM does not support multi base natively. So it is IMPERATIVE to work on only one basis at a time. Having an assembly in one base that uses components from the other base is not a problem for Solidworks but it does cause big problems with the PDM.

The other advantage of multi-base is that each site has its own SQL server (and therefore does not depend on the internet connection to be able to work). We have had internet cuts of several days (fiber optic break on a nearby construction site).

1 Like

Thank you for the answer, in our case the project would be to group everyone on the same site, I imagine that we would need a dedicated server for each base?

For the waiters, it is not necessary.
If you are in the same place, you can have a SQL server and an archive server that contain 3 separate databases.
It is also possible to install the SQL server on the same machine as the archive server.

1 Like