I've heard rumors that we should consolidate our DGNLIBs into one?

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

MaryB — Wed, 08 Mar 2023 16:54:27 GMT

Most definitely.
The truth is, Bentley can suggest whatever they think is best, but I will nearly always default to what works best for my organization. I've been ignoring them (about some things) for years...

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff Martin — Wed, 08 Mar 2023 15:40:58 GMT

this is an issue for those developing and maintaining workspaces for the client.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Matthew Eiben — Wed, 08 Mar 2023 14:42:19 GMT

Bentley did recommend that we consolidate our individual drawing seed DGNLIBs (we may have had 20 or so) into a single DGNLIB to speed up the workspace load time when opening ORD. Which we did. You can see that it's not loading all 20 now, instead only the one. So, some performance increase was noticed. I did see or hear this was being promoted for drawing seed DGNLIBs in different communications, coffee corners, etc. (I don't recall exactly which) so maybe this is what you've heard.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

MaryB — Wed, 08 Mar 2023 14:22:29 GMT

Even if I hear something from Bentley, I'll continue to do what I'm doing - using my clients' standards as delivered.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Zane Pratt — Tue, 07 Mar 2023 23:18:11 GMT

With the recent recommendation by Bentley to merge all drawing dgnlibs really got me questioning their approach. Also their recommendation of defining folder locations for faster download in PW. I have been managing workspaces for 23 years now and simpler is always better. You guys have me wondering about character length now too. Microstation J would crash if dgns or resources had too long of character path lengths and I want to say its limit was 176 characters. There was a reason to our madness of short folder names and file names. :-)

A great test to try is run ORD without a workspace on Projectwise. It screams! Logically the slowness would be the workspace resource files then. So logically removing as many resources files as possible would increase the load speed and processing speed. Right?

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Mark Plum — Tue, 07 Mar 2023 22:56:29 GMT

Excellent, Robert!

Mark

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Mark Plum — Tue, 07 Mar 2023 22:55:58 GMT

:-)

I am suggesting your most recent post, Jeff, as an answer to our issue.

Mark

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff Martin — Tue, 07 Mar 2023 22:30:10 GMT

ILikeTheFactThatTheFileNameTellsWhatsInTheFileButYeahThereAreCharacterAndDecencyLImits.dgnlib

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Zane Pratt — Tue, 07 Mar 2023 22:17:35 GMT

Robert,

Great Reply, Character length still does still matter! Also special characters matter. I have seen ORD issues with use of special characters in feature definitions, file names and even folders on Projectwise. i.e. we had files in Projectwise that weren't printing correctly. The folder had special characters so we renamed the folder and the problem was solved.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Robert Garrett — Tue, 07 Mar 2023 22:09:14 GMT

We are advising all our clients to skip the mega use of wildcards for loading libraries and instead explicitly define every file needed in the CFG file. This has two benefits:

It is noticeably faster to load the workspace and open files.
Following the Bentley pattern of CFG files results in ridiculously long file names which are offensive, plus if workspace is on a network drive, you can still get into trouble when the path plus filename exceeds 256 characters.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Robert Garrett — Tue, 07 Mar 2023 22:04:44 GMT

Mark Plum the reason I like utilities sperate is because utility features tend to be extremely similar in every jurisdiction. With a separate utility library, I can easily migrate the library from state to state and town to town with very little effort other than changing levels in the element templates.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff Martin — Tue, 07 Mar 2023 21:57:14 GMT

thank you, Mark. I look forward to your results.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Mark Plum — Tue, 07 Mar 2023 21:40:11 GMT

Zane:

Thanks so much for your work here; much appreciated!

I do wonder if "also to increase speed try adding a custom variable defining the dgnlib resource folders and get rid of the wildcards used in dgnlib variables. (*) . Typing out the full file names seems to load files a little quicker in Projectwise" would work for a standard Work Station installation... certainly worth a shot and wouldn't take much time to accomplish. I will try and carve out some time and test this- your- idea and get back with y'all on it!

Mark

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff Martin — Tue, 07 Mar 2023 21:35:35 GMT

Thanks, Zane. San Diego is PW-based, so your recommendations have direct relevance. So, what triggered your test? Is there a recommendation from Bentley out there? I'd sure like to get actual Best Practice Recommendations (and supporting data) from the vendor. They have a unique ability to see patterns and enough data to provide quantitative recommendations - if they were determined to do so. We'd all benefit. In the meantime, I am grateful to you and the other contributors to the forum, who help us out even though it is not their job to do so.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Zane Pratt — Tue, 07 Mar 2023 21:06:05 GMT

Jeff,

I tested this theory with one of our DOT workspaces and I did see a significant speed difference in ORD on Projectwise. I went extreme on my testing and put all the resources in one dgnlib. The only exception was a separate dgnlib for civil cells and a separate dgnlib for drawing seeds. ORD is always pulling resources from dgnlibs , even certain commands will trigger a scan of resources. (place dimension) This is opposite of v8 when resources were loaded at the beginning of the session and that was it.

This theory is worth looking at. I think some resources in multiple dgnlibs conflict with each other at times.

Also to increase speed try adding a custom variable defining the dgnlib resource folders and get rid of the wildcards used in dgnlib variables. (*) . Typing out the full file names seems to load files a little quicker in Projectwise. Projectwise isn't wasting time searching and scanning folders for files. The files are already downloaded before the dgnlib variables are even set.

This is My Two Cents

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff Martin — Tue, 07 Mar 2023 20:13:15 GMT

Thanks, Mark. All else being the same, I'd rather laugh while working. Fun is an overlooked quality metric. It's not particularly welcome in some places, though (government agencies have concerns about public records). I think (hope) we're safe here.

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Mark Plum — Tue, 07 Mar 2023 20:08:46 GMT

LMAO... your humor is certainly welcome out here, Jeff!

We are going to stick with what we have as well. We have so much data that even a slight rebuild would take serious time!

Mark

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Jeff Martin — Tue, 07 Mar 2023 19:01:31 GMT

Thanks. If Robert and Mark agree, then it's case closed: bad rumor. Unless I hear something from Bentley, then we stay with what we're doing. Thanks!

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Mark Plum — Tue, 07 Mar 2023 18:50:18 GMT

Oh, and one other thing: Jeff asked "If consolidating into fewer, what are the advantages to balance out the disadvantages?" I do suppose that one large library will load faster than many libraries of the same combined size (advantage). The disadvantage is also provided by Jeff: that is " I know the disadvantage of consolidating into a single omnibus dgnlib (twenty surgeons working on the same spleen doesn't work very well)".

Best Regards,

Mark

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Mark Plum — Tue, 07 Mar 2023 18:47:19 GMT

Robert:

My two pennies here...

Library 1 has all which you have stated but also utilities (a single library for drainage AND utilities).

Library 2 and 3, identical to what you have here.

What we really have done is to be rid of the separate text favorites and labeler dgnlib's.

Best Regards,

Mark

RE: I've heard rumors that we should consolidate our DGNLIBs into one?

Robert Garrett — Tue, 07 Mar 2023 18:06:10 GMT

My 2 cents: No, not a single DGNLIB for everything but I do favor keeping things compact per discipline. For example:

Library 1 has everything related to drainage (feature defs, text favorites, element templates, labeler and annotations setups, possibly even text styles related to drainage makes sense in some instances)
Library 2 contains all of roadway
Library 3 contains all of survey
Library 4 contains all of utilities.
etc.

This greatly simplifies library maintenance