Project Archiving - Xrefs and drive letters?

[VirtualBuilding]

CAD Projects are typically stored on the network at a fixed location, we'll call it P:\
This is typically a raid array, fast server, expensive "active" space.
Eventually that data is "old" and needs to be moved somewhere to make room on the "expensive" server.

Our solution has been to keep the data "live", but on a cheaper IDE raid server. we'll call it Y:\
The problem exists when you go to access that old data.
The xrefs don't work when someone accesses the "old" projects, because P:\ is now Y:\

Granted you could use Xref Manager to fix them all, but every time you archive a project?
Or you could switch drive letters back and forth, but that's tedious too..

Surely there's a better way using technology?

[mtlynn]

We have the same situation here, our archive dir. doesn't really have a drive letter. But we never never open a drawing from that dir. either. We move it back to the active server and open it there. The archive server is also only read only. Hope this helps.

[VirtualBuilding]

Project structure is and ability to setup projects is locked for the average employee. This preserves project structure and prevents "unauthorized" project work. Basically requiring project managers to communicate with the Financial departement. :)

So in our case, moving files back and forth would get very messy.

[Wanderer]

Granted you could use Xref Manager to fix them all, but every time you archive a project?
Or you could switch drive letters back and forth, but that's tedious too..
What about, when creating new projects to have the paths set at 'relative'? would that work? so, yeah, you'd still have to use the reference manager on the existing projects, but, it would prevent the problem in the future.

[VirtualBuilding]

Never had much luck with the relate path thing...
When you have a Standard that dictates filenames as well as folder, won't the relative
path cause you to get the first "titleblock" in the project list, instead of the correct one from your project?

Honestly I don't know much on this subject. Always hard pathed things in past... might be from ignorance, maybe from habit.

[Wanderer]

Never had much luck with the relate path thing...
When you have a Standard that dictates filenames as well as folder, won't the relative
path cause you to get the first "titleblock" in the project list, instead of the correct one from your project?

Honestly I don't know much on this subject. Always hard pathed things in past... might be from ignorance, maybe from habit.Relative is slightly different from what you're thinking of (when you get a project with x-refs and just dump the titleblock in the same folder it will see it), but, with a relative path, think of getting your directions backwards.
So, instead of saying
Drive R > Main Folder > Project Folder > Project 'A'
Drive R > Main Folder > Titleblock Folder

You'd be telling acad i'm in folder project 'a' > Project Folder > Main Folder > Titleblock folder

:Oops: I'm sure I didn't explain that well... I should look it up in 'help'...

[Opie]

Relative is slightly different from what you're thinking of (when you get a project with x-refs and just dump the titleblock in the same folder it will see it), but, with a relative path, think of getting your directions backwards.
So, instead of saying
Drive R > Main Folder > Project Folder > Project 'A'
Drive R > Main Folder > Titleblock Folder

You'd be telling acad i'm in folder project 'a' > Project Folder > Main Folder > Titleblock folder

:Oops: I'm sure I didn't explain that well... I should look it up in 'help'...
At first I thought you were a little off on that explanation but it is right with your example. You have to tell the computer you are in this Project Folder but want to get to the Titleblock Folder. If you had to get to that TitleBlock Folder from the Project Folder you would need to first step back to a common folder that the two folders shared. A relative path must be located on the same drive as well.

You would need to use the following path to get to that folder.

..\..\TitleBlock\titleblock.dwg

[Wanderer]

At first I thought you were a little off :neutral: hey, I resemble that remark... ~keeps reading~


on that explanation but it is right with your example. You have to tell the computer you are in this Project Folder but want to get to the Titleblock Folder. If you had to get to that TitleBlock Folder from the Project Folder you would need to first step back to a common folder that the two folders shared. A relative path must be located on the same drive as well.

You would need to use the following path to get to that folder.

..\..\TitleBlock\titleblock.dwgThank Richard, I believe that is slightly more clear than I'd muddied it, I mean, made it. ;)

[VirtualBuilding]

That makes sense, I just need to try it now before passing it along.

As you said, this would take care of the problem going forward.
Not having tried it though, would I be able to use Xref Manager to remap
the entire "archive" drive with Relative paths?

[Opie]

That makes sense, I just need to try it now before passing it along.

As you said, this would take care of the problem going forward.
Not having tried it though, would I be able to use Xref Manager to remap
the entire "archive" drive with Relative paths?
It is all time consuming, which ever way you go.

[michael.12445]

AutoCAD's handling of reference files is extremely clunky. It remembers drive letters as part of the xref paths, rather than UNC names, and has no facility globally to change these throughout a set of drawing files. (Xref manager works on only one drawing at a time and won't change paths recursively in nested xrefs.) If your server storage is on a Linux machine, you can make a symlink from the "expensive" storage to the archived location on the "cheap" storage, meaning everything would still appear to the workstation to be located on "P", even though the archived files actually reside elsewhere.

Or, a kluge you can use at a workstation is to remap drive letters temporarily, so that "P" points to the "Y" location. A single location can have more than one drive letter mapped to it, but of course each drive letter can only be mapped to one location. If you do this, however, you would need to undo the remapping when you are finished using the archived files.

Michael Evans

[Wanderer]

(Xref manager works on only one drawing at a time and won't change paths recursively in nested xrefs.) to clarify for those who haven't used it... Xref Manager works from within autocad on the active drawing... the separate app, the Reference Manager will work on many drawings at once... ~back to your regularly scheduled program~

[VirtualBuilding]

to clarify for those who haven't used it... Xref Manager works from within autocad on the active drawing... the separate app, the Reference Manager will work on many drawings at once... ~back to your regularly scheduled program~


Ooo.. Good catch... Yeah what she said ;)

I meant Reference Manager... the one that works on multiple files at once.

[james.eustace]

I may just be over simplifying this or not really understanding what you're trying to do ( seems to be the case on most of what I read on this forum) but why don't you just bind the xref to the file you're archiving?

[Mike.Perry]

Hi

Have you looked at implementing ProjectName ( refer to the AutoCAD Online Help File "F1" for details on this facility, if required ).

+

The following Technical Documents might be of interest...

ID: TS63072 - Use relative paths with external references (xrefs) (http://usa.autodesk.com/adsk/servlet/ps/item?id=2888419&linkID=2475323&siteID=123112)

ID: TS73888 - Relative paths for external references may load incorrect drawing (http://usa.autodesk.com/adsk/servlet/ps/item?id=2892307&linkID=2475323&siteID=123112)

ID: TS17814 - Cannot load xrefs from network (http://usa.autodesk.com/adsk/servlet/ps/item?id=2881669&linkID=2475323&siteID=123112) ( Michael Evans maybe interested in this one, seeing as UNC work perfectly with Xrefs ).

ID: TS72473 - Remove or replace all xref paths in a drawing (http://usa.autodesk.com/adsk/servlet/ps/item?id=2890235&linkID=2475323&siteID=123112) ( Michael Evans maybe interested in this one, seeing as UNC work perfectly with Xrefs ).
[/url]
ID: TS69565 - [url="http://usa.autodesk.com/adsk/servlet/ps/item?id=2867918&linkID=2475323&siteID=123112"]Set up PROJECT feature (http://usa.autodesk.com/adsk/servlet/ps/item?id=2890235&linkID=2475323&siteID=123112) ( Michael Evans maybe interested in this one, seeing as UNC work perfectly with Xrefs ).

Have a good one, Mike

[VirtualBuilding]

I may just be over simplifying this or not really understanding what you're trying to do ( seems to be the case on most of what I read on this forum) but why don't you just bind the xref to the file you're archiving?


Your experiences with Binding must be different from mine. I'd rather use the Reference Manager, it would be shorter. We've had no end of problems trying to bind our drawings together. There seems to always be something that causes it to fail! :(
No worries though, it's a rare day, these days, to have someone want something bound... now that we have Etransmit! :D

[sinc]

I've just been dealing with this issue.

For the most part, we use relative paths in XREFs, and that works fine. But there is one issue that causes problems.

We have some large areas where we have a number of projects. We have set these areas up so that all the base linework for the entire area is in its own project, and the base linework is referenced as needed. The base project may stay current for a long time - much longer than the individual projects - but eventually, it too will need to be archived.

The issue is that, if the base drawings are XREF'd in using relative paths, these paths get broken when the project is archived. If the base drawings are XREF'd in using complete paths, the paths are broken when the base drawing is archived.

I've started using the PROJECTNAME variable to control this. It seems like it will work. However, this has a couple of issues. The first issue is the fact that the paths associated with these PROJECTs are set in the Options, and stored in the Windows Registry. This makes administration something of a pain - when a base project is archived, the path must be changed on every computer. Well, I've heard of Group Policies, and maybe that's the solution for that problem - I don't know. I'm not really a Windows sys admin, I just get stuck with the task... ;) It find myself wishing this could be configured via a configuration file instead of the Windows Registry.

The second issue, of course, is now I need to train several people to use the PROJECTNAME setting. It would be nice if this feature was better-integrated with the XREF manager. It almost seems like a feature someone at Autodesk added to R14, then they forgot about...

I'd also like to be able to hook a PROJECTNAME to a Land Desktop project, so that anytime a new drawing is created in a certain project, the PROJECTNAME variable is automatically set to the correct value.

[CadDog]

Has anyone here heard of a program called XRP by MMcD...???

Xref Relative Path Utility v3.2

[Michael Coviello]

I've used this with good success:
http://www.intelcad.com/pages/xrepath/index.htm

If you don't want to go through the trouble why not just map a drive with the appropiate letter which would resolve the xref? (a temporary fix)

[Hammer.John.J]

I think this problem stems back to how your organize your drawings wholistically.

If you were to put all of your xrefs in a folder like 1 drawing set.... see below

server mapping:
\\server\sdksproj\2564-1\dwg\current\

work station mapping:
\\server\sdskproj\=G:\

LDT see's it like this
PROJECT PATH: G:\sdkskproj\
PROJECT NAME: 2564-01
DRAWING PATH: G:\sdskproj\2564-01\dwg\current\
therefore, you place all drawings that are used in the set into ..\..\..\current\
when it gets moved to archive regardless of the mapped drive it will find all of the xrefs

the issue become when you put your cad files per drawing set outside of each other. If you need a titleblock for every job, it is so small just add it to the drawing set sub directory for each job... problem solved.

HERE'S MY POINT
Autocad regardless of it being ADT LDT etc wants all the xrefs to be in 1 central location.

We rename all of xref "names" in the drawing so that they are sorted in a certain fashion
ex: our survey's or "base" drawings are always named Z-Base in cad, but maybe Survey.dwg (usually they are Z-Base.dwg) but you get the point.

If you have 100 cad files for a job, this could be an issue but at that point you probably need a naming system for the file TYPES, probably a numeric system.

edt:
i forgot something:
we work like this:
we have a current folder for day to day ongoing revisions
we have an "archive" folder that contains dated zip files of every submission or email or transmission that contains every cad file for the set.
the archive acts as a snap shot and allows you to continue working on the same drawings from concept to construction/stake out AND all projects have the same project setup

when we archive we archive the entire project as is, basically move it from 1 server to the next

[Jordan Truesdell]

ID: TS73888 - Relative paths for external references may load incorrect drawing

Holy Schnikes, Mike! That's got to be a good candidate for the bad software coding hall of fame. If I set a relative xref, I expect autocad to look for the xref *relative to the location of the referenceing file*. How hard is that? FWIW, I've not encountered this bug, but I often open files from the explorer windows, since Autocad often leaves me in a directory I don't need, and it's easier to keep three or four explorer windows open with the files I need to build a new project.

As for the topic - I have switched exclusively to relative xrefs for all the problems the OP mentioned. It also means nice zips to send to clients, since there is no wacky directory structure to send (I've gotten some with more directories than actual files).

[sgoodmansen]

Came late to this thread, however I can offer the solution i came up with my firm.


all active projects reside on P: After they die or complete the PM culls the drawings and copies everything to a temporary drive Y then deletes the job on P:. Periodically I check Y: and if there is anything there, I zip it up and move it to a read Only drive called R; Only I have write access to this drive. If somebody needs something they extract it to their computer.

The xref's should be bound before being zipped, however it really hasn't caused many problems for us either way.

The advantages are the Archived projects can't be messed with. I back it up on another drive and on Tape any time I make changes to the R; drive. zipping saves space,

The disadvantages of the method are trying to get the PMs to archive their own work. I usually end up doing it all. Its also not easy to just open the drawings since they need to be extracted first.

Steve

[ahensley]

I second that. If a project is archived, it should techinically never be changed again. Therefore it is safe to bind all xrefs to the drawings for permanent storage.

Our firm has a batch routine (written in VBA) that binds all xrefs in the drawings we select via a dialog box. The project is then moved to the archive location (a separate drive letter).

This makes binding efficient and easy to manage.

[richard.binning]

I took the vba route as well, although of a different flavor (flavour to some of you).

All active projects maintain hardcoded paths using mapped drives.
When it comes time to archive the project, the user runs an ObjectDBX enhanced vba routine to copy the entire structure and set of files to another drive. The routine effectively allows us to create wholesale duplicates of projects. Features of the routine include:

Ability to choose different drive letter (The routine will repath all images and xrefs attached so that files when opened from the new drive will find all their resources at the new location.)
Ability to choose a different project number. (With this option, the files themselves are copied to the new location with a new project number folder at the root, then the file is accessed and any xrefs, images, or blocks are renamed to match the new project number. The routine then repaths all images and xrefs attached so that the files when opened from the new drive will find all their newly renamed resources at the new location.)
Ability to apply "Relative" pathing to the process. (This option strips off the drive letter and folder names to the level of the project replacing them with relative paths - relative to the main project folder.)
ObjectDBX enhancement comes into play by allowing the files to be accessed, modified, changed, and saved without opening them to the running AutoCAD session. I have processed 1500 drawings in less than 30 minutes using this routine.

We've had a number of projects that were slated for 40 Manhours of "adjustment" to prepare them for re-use on a new site that were ready for use in minutes instead of a week by use of this routine.

RLB

[michael.12445]

I took the vba route as well, although of a different flavor (flavour to some of you).

All active projects maintain hardcoded paths using mapped drives.
When it comes time to archive the project, the user runs an ObjectDBX enhanced vba routine to copy the entire structure and set of files to another drive. The routine effectively allows us to create wholesale duplicates of projects. Features of the routine include:

Ability to choose different drive letter (The routine will repath all images and xrefs attached so that files when opened from the new drive will find all their resources at the new location.)
Ability to choose a different project number. (With this option, the files themselves are copied to the new location with a new project number folder at the root, then the file is accessed and any xrefs, images, or blocks are renamed to match the new project number. The routine then repaths all images and xrefs attached so that the files when opened from the new drive will find all their newly renamed resources at the new location.)
Ability to apply "Relative" pathing to the process. (This option strips off the drive letter and folder names to the level of the project replacing them with relative paths - relative to the main project folder.)
ObjectDBX enhancement comes into play by allowing the files to be accessed, modified, changed, and saved without opening them to the running AutoCAD session. I have processed 1500 drawings in less than 30 minutes using this routine.

We've had a number of projects that were slated for 40 Manhours of "adjustment" to prepare them for re-use on a new site that were ready for use in minutes instead of a week by use of this routine.

RLB


Richard,

Sounds like something that oughta be in AutoCAD itself, but isn't. Our IT staff is struggling with this very issue, as we recently merged and had to re-map drive letters when we plugged our servers into the main company's system. May I have my IT guy contact you about this?

Thanks

Michael Evans

[Mike.Perry]

Sounds like something that oughta be in AutoCAD itself, but isn't. Our IT staff is struggling with this very issue, as we recently merged and had to re-map drive letters when we plugged our servers into the main company's system. May I have my IT guy contact you about this?Hi

Have you looked at using Reference Manager that comes with AutoCAD ?

Have good one, Mike

[Comach]

Most of the available options have already been mentioned.

We had similar issues and use the ProjectName option which works well for us - this only needs to be done once for each project as the value is saved in the Windows registry.

For archiving old projects we would not bind the xrefs as they are a useful resource for future projects or if we have to restore a project for new work - extension or refurbishment.

For sending cad data out to clients we would use the publish option which will search and retrieve xref files to be compiled together in one file either EXE or Zip.

[michael.12445]

Hi

Have you looked at using Reference Manager that comes with AutoCAD ?

Have good one, Mike

Yes. While Reference Manager can alter xref paths in multiple drawings at once, without opening each one in AutoCAD, it does not address the problem of nested xrefs (unless I'm missing something). So if Drawing A references Drawing B, which in turn references Drawing C, updating the references in Drawing A isn't enough. Unless the references in Drawing B are also updated, when you open Drawing A, it will load Drawing B and then attempt to load Drawing C according to the path information stored in Drawing B, not that stored in Drawing A.

Therefore, if you have a big set of drawings that you want to move from one drive letter to another, you have to start at the bottom of the xref tree - where the host drawings only reference drawings that don't contain any xrefs - and work upwards. So it's still pretty labor-intensive.

Of course, the easy kluge is to remap drive letters to match the original paths. But in our situation, several drive letters have already been "claimed" by the previously established office standards of the firm with which we merged.

But when I go home, there is no CAD and no Windows, just a Linux box complete with symlinks and no drive letters...sanity.

Michael Evans
Togawa Smith Martin Residential, Inc.

[richard.binning]

Yes. While Reference Manager can alter xref paths in multiple drawings at once, without opening each one in AutoCAD, it does not address the problem of nested xrefs (unless I'm missing something). So if Drawing A references Drawing B, which in turn references Drawing C, updating the references in Drawing A isn't enough. Unless the references in Drawing B are also updated, when you open Drawing A, it will load Drawing B and then attempt to load Drawing C according to the path information stored in Drawing B, not that stored in Drawing A.

Therefore, if you have a big set of drawings that you want to move from one drive letter to another, you have to start at the bottom of the xref tree - where the host drawings only reference drawings that don't contain any xrefs - and work upwards. So it's still pretty labor-intensive...


Thats right, I believe, that was another reason I wrote the batch routine in VBA. The other reason is the block name itself. If I attach an xref named 34567FLR.dwg, it's xref name will be 34567FLR. If that file is repathed using Xref Manager, the block name doesn't change. So now 34567FLR is really pathed to 45678FLR.dwg. Things can get confusing, hence the VBA routines ability to also rename the internal block name. The XRef manager does a good job under a limited scope. It takes custom coding to go to the next level.

RLB

[michael.12445]

Thats right, I believe, that was another reason I wrote the batch routine in VBA. The other reason is the block name itself. If I attach an xref named 34567FLR.dwg, it's xref name will be 34567FLR. If that file is repathed using Xref Manager, the block name doesn't change. So now 34567FLR is really pathed to 45678FLR.dwg. Things can get confusing, hence the VBA routines ability to also rename the internal block name. The XRef manager does a good job under a limited scope. It takes custom coding to go to the next level.

RLB

It sure does. So, tell me again, what is it we are paying Autodesk for?

Michael Evans
Togawa Smith Martin Residential, Inc.

[thillhouse]

Has anyone had any good experience with Project Browser/Project Navigator in ADT 2005? It is supposed to keep the paths and repath them if you move the project to another drive. One pitfall is you have to use the "Construct..Element...Sheet" format that is inherent in the project navigator setup...

I've used it once, but had several consultants that didn't use it so it really only worked for some of the files and sometimes did not catch all the xrefs...

I don't think I will use it in the future unless BIM takes off or we are required to by contract...

Tim