Actually, I think you may be right, and you certainly won't be castigated ("shot") for speaking your mind. Remember, though, what is important here - the museum personnel reading this may not themselves be programmers, and their institutions may not even have programming resources on site, but these personnel and institutions DO understand the material they are cataloguing, and the requisite information that must be managed. These functional definitions dictate, in my mind, the direction any technological solution will take. Take as an example the situation that got this whole thread going. The knowledge of how dates must be handled in relation to the items being catalogued is the key (IMHO) to what solution makes the most sense. If a certain degree of dating accuracy is necessary, or if queries on the data involve a certain range of dates with a certain amount of variance - these functional needs will determine whether an simple integer field can handle the requirements, or a different approach is required (i.e. a .DLL with formatting, verification and parsing capabilities). The cataloguers themselves probably won't create 100% of most tools, but they must understand 100% of what it does. I certainly didn't mean to get carried away with the mechanics of the particular example we were discussing - the important thing is that there are always more solutions to a problem than one thinks. Thanks for your comments. Charlie Karukstis [log in to unmask]