Who is responsible for documenting the programming and for keeping the 
documentation up to date? What happens when that person no longer works 
for the museum? How relational is the database and do fields "self 
populate"? Are you able to set up sophisticated task management systems? 
How do you handle various styled accession numbers? What about managing 
all the data related to use of an object? What happens when users decide 
they need a new function and how is that new function implemented? Who 
supports the system when it decides not to talk to the rest of your 
software? Does it contain an unalterable audit log? vocabulary 
constraints? Hierarchical access (i.e. the registrar, curator, and 
volunteer can view, add, or change only certain types of data and this is 
security controlled? Can you link objects to processes or places...like 
scheduling them for loans or conservation or link them to storage or 
exhibit locations? Can you maintain an unalterable history of where the 
object's been... 

I can think of a lot of things I might want to do and I'll be darned if I 
have the energy or luxury of time and money to spend programming FileMaker 
to track it all. 

There are a lot of wheels that don't need to be reinvented. Homegrown 
systems reinvent what other programmers dedicate 8hrs/day to doing. 

Flexible....maybe....documented...really? 

Diane
p.s. Robert wrote those essays nearly 10 years ago. Software's changed a 
lot. They're still valuable for understanding what types of processes one 
needs and how one might automate them. 



On Thu, 26 Jan 2006 13:22:40 -0800, David Lynx 
<[log in to unmask]> wrote:

>From glancing over these, I guess it would be how you set it up and use 
it.
>Our FilemakerPro system we have set up does everything that Robert Baron
>classifies as collection management.  We have all object tracking items in
>place, condition tracking, exhibit / loan tracking, etc.
>
>One thing I like about using FilemakerPro is that we can change it and 
adapt
>it to our needs, which is much more flexible than a package system.
>> You will be better served to go to the CHIN site and look at their
>> impartial reviews.
>> http://www.chin.gc.ca/
>>
>> A database is NOT a collections management package.
>>
>> See also Robert Baron's clear and thoughtful writings on the subject.
>> (numbers 3 and 4 in the outline)
>>
>> http://www.studiolo.org/index.htm#Outline
>>
>> Diane Gutenkauf
>
>--
>Yakima Valley Museum
>yakimavalleymuseum.org
>509-248-0747
>

=========================================================
Important Subscriber Information:

The Museum-L FAQ file is located at http://www.finalchapter.com/museum-l-faq/ . You may obtain detailed information about the listserv commands by sending a one line e-mail message to [log in to unmask] . The body of the message should read "help" (without the quotes).

If you decide to leave Museum-L, please send a one line e-mail message to [log in to unmask] . The body of the message should read "Signoff Museum-L" (without the quotes).