Gunter and Moshe maid most of the points, I'd probably just stress why PTC mentions "concurrency" when talking of ESR.
- when you say "concurrency" , if you mean "2 eng's working on same part" - as Gunter said, this is not ESR this is PDM Integrate functionality
- but if saying "concurrency" you mean "we have top.asm with parts A,B,C,D. I want user-1 to work on A & C in assembly context (there are references from C to A), while user-2 to work on B & D" - here you get exact ESR case. You make 2 ESRs from TOP.ASM, each one excludes TOP.ASM and only includes respective components. Benefits :
1. Check Out / In these ESRs - no conflicts on TOP.ASM as TOP.ASM is not checked out by either of them. Work on ESR1 with A & C - add features, relations etc.
2. your Workspace does not get overloaded with unnecessary models (B.PRT, D.PRT, TOP.ASM in our case. Surely all WS operations are times faster.
3.When you check them in back and retrieve the full TOP.ASM you will see that all references between the parts that you created in ESRs will magically update according to any changes that happened in TOP.ASM. This is since ESR manages assembly dependencies in a smart way : not bringint TOP.ASM physically it has all the notion of it and pases this motion to ESR members.
Now above case describes primary usage of ESRs - when default action is "Exclude" and only necessary part components / subassemblies included. However there is also another usage when top assembly is Included in ESR, and some of its subassemblies have most of unrelated components Excluded. Such ESR will differ from regular top assembly simprep only by that it will not download Excluded low level components. hence it is less about concurrency and more about just "lightening" PDM operations and WS size.
Hope this provides some more insight on ESR.
Regards
- Vlad