In this post I've outlined some of the common "health problems" that CodeBook projects can suffer from and how to resolve them. After reading this post, your very next step should be to implement a database maintenance policy on your projects as soon as possible.
Most AutoCAD files need to be purged once in a while, sometimes even "super purged", Revit models too can get clogged up with redundant data and need to be purged, compacted and central files periodically rebuilt - well CodeBook files also require the odd bit of maintenance.
The technical reason for this is that when you add information to a database, space is allocated for that information and when you delete something the space allotted for the information continues to be held in reserve by the database and it is not released for re-use. Likewise, extra space, created by modifying and shortening records, is not released for reuse.
So there are several ways to tidy up or compact your database, you can simply open the database in Microsoft Access and from the Office button select Manage > Compact and Repair Database. If you don't have Microsoft Access installed, or opening up a database in Access scares you - you can do this in CodeBook through File > Compact Project.
From within CodeBook you can also set the database to Auto-compact once it gets to a certain filesize. From the Project Properties window > Database Settings, there is a box labelled "Auto-compact database at size" in which you can enter a number.
As mentioned in a previous post, you can have a single database which stores all of the buildings, departments and rooms - but you may also choose to split this up into several more manageable databases when working within a team environment with multiple Revit FF&E models and users accessing and contributing to the data. This has it's pros and cons of course, typically I try to keep project database size to under 15mb wherever possible.
In addition there may be redundant data lurking in your database, which should, but has not yet been deleted. What I mean by this are things like, unlinked rooms no longer in use, duplicate rooms, lookups created by mistake, room data templates copied in error and equipment that someone else must have created??
I'm stepping into slightly dangerous turf here... but I'm a firm believer in not carrying around unnecessary baggage within files and blasting away data that is not actively in use. BUT, before doing so take some time to double check the data is definitely not being used, think it through, take a backup of your files and talk to others.
The odd unlinked (red) rooms will be common in the early stages of a project, but once the planning has settled down, the 1:200 departmental layouts have been signed off and you enter the Design Development phase you should ideally have a database full of linked (blue) rooms and a Revit model full or rooms with parameter Linked_Status = 'Valid Link'
Unlinked rooms in CodeBook may originate from the schedule of accommodation (space programme), a room may have become accidentally unlinked or even deleted from the model and so a "due dilligence" check needs to be carried out before it is deleted. In order to check this, I would first run a full synchronise for the project so all linked rooms are coloured blue in CodeBook and each linked Revit Room has a Linked_Status parameter value of 'Valid Link'.
There are lots of wonderfully technical ways to review these, but I find a visual "common sense" check is normally the quickest and best method. A quick eyeball check of each department will identify unlinked rooms in CodeBook and through a Revit schedule you can identify any unplaced or unlinked rooms in Revit. Using a combination of the CodeBook display rooms function, find room using BIM hit and the Revit function Show (from within a schedule) will zoom you to any rooms that you need to check.
New and experienced users will generate extra lookup values and room data template duplicates, whilst developing the project. Often this happens by a lookup value simply becoming obsolete, for example, a type of floor finish might be specified early on and subsequently be deleted from the scheme. Also templates may be duplicated in error and then not removed.
You may ask yourself why would someone do this - i.e. create unecessary data? Using any software is difficult before it becomes easy, and it's always easy when you know how.
Before getting rid of these items, you should first check if and where they are being used - i.e. assigned to a room and form part of that rooms data. To do this we generate lookup and room data template usage reports, which list out the rooms that are using the value or template.
From within the Lookups Editor or Room Data Templates window, you can generate these usage reports quite easily. (note, you'll need to do this for each project database)
Equipment can also become redundant and again, like lookups and templates, we first need to assess whether these are in use within the project before removing them. If you suspect an item is no longer in use, then if you browse to the item in the Equipment Library window, you can generate a usage report by selecting File > Usage Report.
You can 'Hide' individual items of FF&E, but if you are confident using Access, or even Excel based formula's you will be able to work out which items exist within your project as required or designed equipment, and compare this against the overall equipment in your library. Once you have identified the equipment that you want to hide, there is a nifty and fairly recent function that will let you do this en masse.
From Librarian > Update Data > Batch Hide Equipment, this will open a window with 2 buttons, select "Create xls file of current library" and CodeBook will generate an excel list of the equipment within your library.
The excel file has a column 'Show or Hide' which you can edit accordingly. Once you've finished editing your excel file, select the Update button, browse to your freshly updated xls file and CodeBook will do the rest.
So many times I've heard people say "Well I didn't create it, so I'm not going to delete it." But these are normally the same people who complain about having too many lookups, or templates they know should be removed.
Everyone should be responsible for keeping the project dataset lean and mean, and whilst it may not be everyones role to remove redundant data you should encourage your team not to suffer in silence. Hope this gives you a few ideas...
No comments:
Post a Comment