Hello
Since EPDM allows you to synchronize some directories of the local view when connecting, I wonder if I can use this on the entire vault.
I am currently using it on the directory containing the blocks, basemap... and it works well.
Did anyone have fun doing it on the whole safe?
There are only a few people in my company (6 EPDM users) so the number of files modified in 1 day should not be too large. The loading time at the connection should therefore be limited for a gain in speed of use the rest of the day (almost no files to load from the network, everything would be locally on SSD) and less problems of opening/working on obsolete versions.
What do you think of this idea, have you ever tested it?
Thank you for your feedback
Hello @froussel,
I haven't had the opportunity to use this option, but reading you, something "scares" me: you'll end up with ALL the chest (in the latest version) in your local cache???
You would have to look at the number of files (and especially their total volume), that you can have, but for my part if I had done that in my current company, but also in the previous one, I would have quickly saturated my hard drive!
1 Like
@Benoit LF
First of all, thank you for your comment
We have 80 GB of data in our safe so it fits well on a 256 GB SSD ;-)
Since we only get the latest version, the local disk is much less solicited than the server disk which contains all the versions of all the files.
I've already done the manipulation for my 40 GB USA database, the longest is to do the command on parts of the local view (10 to 20 directories) and let EPDM mill (it looks for all the file references for assemblies and drawings). Another advantage once the entire local view is synchronized is to be able to make a copy of the local view (which is a backup of the 3D files that can be used directly, not like the backup of the vault which only contains files 0001, 0002... useless without the SQL database).
Your remark is the reason for my question. It may lead to heaviness at the morning connection or other negative effects (other than the volume of data which is quite easy to know/control).
I launched the manip for my user. If I finished syncing my local view tonight I would put the entire vault in local cache tomorrow morning with the 'refresh cache during login' option of the user properties.
1 Like
To close my intervention, and from a purely theoretical point of view, I don't see any reason for difficulties since the number of files modified every day remains limited.
And this approach has the big advantage that in case of a server glitch (unavailability of the data server or the sql), EPDM users have all the data they need to work without a network!
@Benoit LF
In practice you could work on a copy of your local view, but then hello reimport...
You probably can't work live in your local view because if you don't have a connection with SQL, you won't be able to do anything.
You would have to go offline BEFORE having a problem (which is quite unlikely except in case of planned server maintenance where your BE could work for a day or two offline)
What happens if you systematically have all the latest versions on your local cache when you open an assembly of an old machine from your station ?
You will no longer have the "real" image of your machine on your station, you will have all your files at the latest version while maybe at your customer there will be a difference in clue.
Personally I find it dangerous, according to the revision policy that you have in place in your company.
It seems to me that there is a MyPDMTools utility to do this and that can automatically update (at a fixed time every night for example) your local cache
1 Like
@flegendre, the local cache refresh option is now built into EPDM! :)
Agree with your remark about the "as-built" machine, but it seems that many use the "latest version" option.
HS: @froussel, why do you talk about local view copying? You can work directly in the local cache!
If the connection is not made with the server, you can connect offline (the folders are blue as a result), and you can create files in the EPDM tree.
When you reconnect the server, you will have to right-click on the "Add to Data Vault" files.
1 Like
@flegendre:
Just because you have the latest versions of all the parts/assemblies in your cache doesn't mean you can't ask EPDM to load an assembly in its 'as built' version (or in any other version). Instead of opening the assembly directly, you just have to 'get the version' and EPDM will offer you to reload the parts that have taken versions and allow you to open the assembly as 'as built'
A rather interesting topic on the subject:
http://blog.design-point.com/blog/2013/february/as-built-vs-lastest-versions-of-parent-references-get-it#.VqHnZlLKuDA
The brave can even have fun creating shared files to have the same part or assembly to different versions in their local cache (not recommended for novices...)
In our business, in practice, we almost never assemble versions once the assembly is delivered and we almost never deliver the same assembly twice (and if we have versions of parts, these are generally interchangeable, so it's transparent in terms of assembly). So we work most of the time with the latest version of documents.
Thanks for the info on the PDM tool, I'll dig into this option.
@Benoit LF: I'm not sure you can go offline if you don't have a connection to the SQL server. So you have to go into offline mode (and choose the files you need to extract) BEFORE the link is lost. On the other hand, the fact that you have the entire trunk locally means that you will be less stuck in offline mode since you will be able to at least insert any part/assembly in your designs (even if you can't modify them since you didn't extract them before going offline).
First feedback of use: the log time is extremely long even when there is no/few files to synchronize: we go from 9s on a local view whose cache was emptied the day before to 2min42s on a fully synchronized local view. This is probably due to the fact that we query the SQL database at the start of the transfer to know the versions of all the files present in the local view (and since I have all the files (65600 in my case), obviously it's much longer than if I didn't have any in the local view). The given times are just the log times on the local view (display of the folders in green). They do not take into account the time it takes to download unsynchronized files.
Apart from that, I don't see any major drawbacks for the moment.
Not much to add to my last post.
It works well except for the log time which is a bit painful in the morning (but it allows you to read emails...).
The big plus is that we have almost no more files that are not synchronized (only the ones that my colleagues modify during the day).
Is the morning loading time compensated by having to 'get the latest version' less often? Not sure.