> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Tim Churches > Sent: Friday, 6 January 2006 12:42 PM
Source code also allows feedback on mistakes. For example, it is not a good practice to hard-code a timezone offset of GMT+10 hrs into date/time fields, but I recall that Argus is guilty of that in some places. Not a fatal flaw, but one which could usefully be fixed to prevent grief if/when Argus is used in both Perth and Sydney, for example. Of course, similar flaws may exist in many other, closed source products, but we'll never know (until perhaps it is too late and the consequences of such bad programming practices bite end users). *** I can support this with a story from my own experience. Those of us who used the PICK-based Medrecord software (which had many good features) had that experience when we reached a certain day several years ago. The PICK operating system and database stores dates internally as the number of days since 31st December 1967, so that 1/1/68 was day 1 and a month later was day 31 and a year later was day 365, and so on. Several years ago, the PICK internal date was 9999 and the next day became 10000, moving from 4 characters to 5 characters. Guess what some programmers at Medrecord had done, while they were programming in the 1980s ? Yup, they had specified the internal date field as being only 4 characters long. Medrecord charged users quite large amounts of money to fix this problem that they blamed on the PICK operating system rather than on their programmers' lack of foresight. With some advice from other experienced users, it took me one minute to fix the problem on my practice's Medrecord system. Oliver Frank, general practitioner 255 North East Road, Hampstead Gardens South Australia 5086 Ph. 08 8261 1355 Fax 08 8266 5149 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
