With GT.M mupip integ is an easy way to tell if the integrity issue is at the database structure level.
I endorse Greg's comments about error trapping with one caveat - if you trap an error, don't ignore it (unless you are really, really sure you know what you are doing) and remember to log it. Some of the hardest debugging problems occur when errors are ignored and thrown away. Also, do monitor the system log or operator log (it's the same thing on Linux) - /var/log/messages typically, but there are different logging packages around - for messages from Linux (about disks being full) and from GT.M. Indeed, you should check for full disk conditions. System hygiene, especially for production systems, is as important as brushing your teeth regularly. -- Bhaskar -----Original Message----- From: [EMAIL PROTECTED] on behalf of Gregory Woodhouse Sent: Mon 4/4/2005 12:54 AM To: [email protected] Cc: Subject: [Hardhats-members] Maintaining database integrity I've noticed there's been a lot of discussion of dangling pointers and other types of database integrity issues at the application level. My experience has been that these sorts of problems are much more common than problems at the global level (i.e., in the MUMPS subsystem). Part of the problem is that updating pointers when a record is deleted is an expensive process, and when deleting records at the application level, people often tend to skip it. A second issue is that Classic Fileman uses a field by field (rather than a record at a time) model for editing that is not always appropriate. In general, using the DBS ("silent") interface can reduce the likelihood of introducing errors (and, in fact, I use DBS calls almost exclusively). A more significant issue is proper use of the MUMPS error trap. I've noticed that many developers tend to look at setting an application level error trap as an "extreme" measure and are loathe to make use of it. I don't believe this a good practice and would argue that it should be used much more than it is currently. One possible issue is that Kernel sets a default error trap that logs errors and application programmers often forget to call ^%ZTER to log the error (as appropriate) and so think that setting the error trap will prevent errors from being logged when they should be. Another issue is that trapping errors is a tool that can be misused (simply ignoring errors like "disk full" can cause database problems). A final issue is that the Standards and Conventions document (SAC) currently does not provide any guidance or standardization in this area. This is something I hope to address. Gregory Woodhouse [EMAIL PROTECTED] ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
<<winmail.dat>>
