Slow Navigation of AC Acroos Network

[Anonymous]

I've read several forums about navigation problems in AC, all of which point to upgrading hardware or updating software. Our office is currently running AC 8.1; all of the computers here are G5's with 1.8Ghz processor, 1GB RAM, and OS 10.3.3 (except for the server which is a G4). we are finding that it takes an extraordinarily long time to navigate the network with AC (and we know that it is AC because this problem does not occur with any other application), sometimes taking 30 sec-several minutes to view the contents of the next folder. It's not the network either; we use CAT5 wiring between all the computers, connecting them with a Lynksis router.

Our next problem is that we cannot sign into a TW project from another computer (after spending such a long time locating the file to open ); .PLP's are accessible only from the computer that they were created on originally. If I try to sign into one from another computer, AC brings up a blank screen as it would when starting a new project with the title "untitled." Help?

[Karl Ottenstein]

Lasse wrote:
Thank you gays!

And straights, too?

[Sorry. Had to beat Dwight to it...]

[Dwight]

Dang!
See what happens when you leave the bunker for salt pork and tobacco?

[Aussie John]

any experiences of networking with v9?

[Dwight]

Well, once you are a beta tester and it gets out, guys have all kinds of questions before they actually upgrade, so I would say that it was good for networking.

[Anonymous]

Karl wrote:

Lasse wrote:
Thank you gays!

And straights, too?

[Sorry. Had to beat Dwight to it...]

oops! Freudian slip?
No really, this helped me a lot. Thank you.

[Anonymous]

I had the same experience as Katie. I never found the solution. I thought that the FTP portion of the Library Manager may have been the issue. I can say that loading our libraries (store on the server) across is still slow. We are Macs (G4, G5, 10.3.4 and 10.2 Server).

I wonder if this is still an issue?

[Anonymous]

For me and I think many people on this forum, loading large libaries from a server is too slow. We put all of our "out of the box" libraries like the ArchiCAD object library and our WindowBuilder libraries on each individual computer. These libraries are never edited and updates are made to each station, to keep them all the same.
Our office standard library and our various project libraries are stored on the server as these libraries are often editted and benefit from the single central location.
This structure significantly reduces library loading time.
Hope this addresses your issue.

[Anonymous]

John wrote:
We put all of our "out of the box" libraries like the ArchiCAD object library and our WindowBuilder libraries on each individual computer. These libraries are never edited and updates are made to each station, to keep them all the same.

Are your models kept on your server? Do multiple users work on the same model? If so, have you had to make all of the hard drive names identical so that the model can find the "out of the box" library on each?

[Anonymous]

We use the same system as John, and we regularly have 3-6 people working on a teamwork file at the same time. Our solution is as follows:

Single user pln access:
"out of box" [OOB] libraries on local drive (all with different names)
office standard.pla and project libraries on server

each time project is accessed from a different machine, the user must select the OOB libraries from their History panel in the Library Manager. To reliably have plotmaker find the library parts, the pln must be opened and saved on the same machine the lbk is opened on.

multiuser teamwork plp access:
OOB libraries on local drive (all with different names)
office standard.pla and project libraries on server

each teammate must add the OOB libraries to the plp. when signing in, the library manager will show 3-6 copies of the OOB library as "not found", but the local copy will still show as loading at the top of the list. DO NOT LET USERS "REMOVE" THE OTHER COPIES AT THE BOTTOM OF THE LIST!!! These paths are stored with the plp and must be there if the library parts in the lbk are to update properly with BGArchiCAD.

If one of the paths gets deleted and a user suddenly no longer sees OOB library parts in the lbk, the user must sign in with exclusive access, add the path to the OOB library, send changes, and then update the lbk.

Its a little bit of a hassle, but until GS adopts relative paths, I haven't found a better way around it. Loading a 131 MB AC8.1 library over the network (even our gigabit net) is far less productive than the simple process listed above.

HTH
wes

[Anonymous]

Weston wrote:
...but until GS adopts relative paths, I haven't found a better way around it. Loading a 131 MB AC8.1 library over the network (even our gigabit net) is far less productive than the simple process listed above.

Thanks. This has bedeviled me since the libraries got so, so large. I hadn't thought to "withstand" the redundancy of unavailable libraries in the Library Manager. I was also loathe to have users suffer going through Library Manager everytime they open a model. However, it sounds like experience has shown you that it is worth it!

I think that Satellite Libraries could be a way that Graphisoft could get a more direct solution (instead of relative paths). If there were a way to allow the teammate to dictate when the model compares the satellite with the source library, networked users could draft on until a directive came to coordinate/update the project's libraries.

I'll try the oob method both of you suggest.