Autodesk FMDesktop
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Creating a new separate database
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
1283 Views, 1 Replies
09-12-2008 08:28 AM
I would like to create a new separate database to track net sq. footages. I'm concerned that my mission critical database might be corrupted (isn't C:\Program Files\FMDesktop\Facility manager 7.1 a common shared resource?)
It would be nice to utilize existing data, but with room numbers to track both net and gross, I believe this would be problematic.
Is anyone doing something similar?
It would be nice to utilize existing data, but with room numbers to track both net and gross, I believe this would be problematic.
Is anyone doing something similar?
Re: Creating a new separate database
Options
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
09-25-2008 08:25 AM in reply to:
Andido
The net and gross are both trackable in 1 database. The net is calculated by the room plines while the gross can use the floor pline when you attach your drawing. Once the drawing is attached and the data is in the table then it is a reporting function for net, gross, useable ect. the important factor is setting up your space standards and defining how you are to pline the rooms to get what you need to report.
As for your worry about the mission critical data being corrupted perhaps you should look at getting the SQL version. You can then set up a maintenance plan to back up your database on a automatic schedule. Another practice to prevent database snafus is to ALWAYS have 2 databases installed. 1 for production and 1 for testing and development. Kind of the "try before you buy" principle.
As for your worry about the mission critical data being corrupted perhaps you should look at getting the SQL version. You can then set up a maintenance plan to back up your database on a automatic schedule. Another practice to prevent database snafus is to ALWAYS have 2 databases installed. 1 for production and 1 for testing and development. Kind of the "try before you buy" principle.
