Hi,
Is there any way of the deleting the automattically saved full path for reference files. One command that I use is "AttachedFile.SetAttachNameDeferred NewFileName". If the NewFileName is not available, Mstn looks back at the last known full path, finds the old file (with a different name) and displays it. I would like it to show as missing if it can't find the new file.
--Thanks, --Robert
Dear Robert,
I have done a similar job on basis of "clean the server" - 120000K file later... yusing Microstation XM
I used
Call oAttachment.SetAttachNameDeferred(sAttachmentPath) Call oAttachment.Rewrite Call oAttachment.Reattach(vbNullString, vbNullString)
where by sAttachmentPath is the new path an file name that may or may not exist - I converted a lot of absolute paths to relative paths and added some confguration variables to the paths too. I am no sure why I added the reatach I think this was to update the drawing to reflect the what the user will see when the drawing is opened first time. I susspect you are missing the rewrite which is needed to commit the change to the drawing.
One word of warning I have many issues processing large numbers of files more than 500 in one microstation session will probably cause microstation to crash - I used 1 microstation session per project but I had 10000k projects.
Best Regards,
Ian Emery
Ian: One word of warning I have many issues processing large numbers of files more than 500 in one microstation session will probably cause microstation to crash - I used 1 microstation session per project but I had 10000k projects.
In general, there is no problem processing many hundreds or thousands of DGN files. We have MDL applications that have been doing just that for many years.
However, there may be a particular problem when the file processor is written using VBA. Others have reported here similar problems of memory leaks when a VBA application is used as a batch processor.
The moral of this story: use the right tool for the job! Microsoft designed VBA as a lightweight rapid application development (RAD) tool, not as a power number-cruncher. Aside from the issue you have raised, there are other reasons why VBA is not, and cannot be, particularly efficient when process large amounts of data.
Regards, Jon Summers LA Solutions