On 3 Nov 2005 at 7:07, dhbailey wrote: > Or what if they released a version without the > "manipulate-temp-files-in-memory-rather-than-on-disk" supposed > improvements.
Bugs don't work that way. First off, there's nothing fundamentally unreliable about in-memory temp data. Indeed, that's really the norm (though very often in combination with on-disk temp files, either as scratch files or to allow backup recovery). The problem is that MakeMusic made some major mistake(s) in implementing their changes to temp file handling. The implementation mistake(s) are the problem, not the feature being implemented. Secondly, you can't just back out a change like this and replace it with the "old" way of doing things, because that process is likely to introduce *more* bugs than it will fix. Third, the speed of autosave (and manual saves) is probably due to this new approach to temp files, so you'd be losing something truly useful at the same time that you're getting rid of the horrid bug. This kind of thing is probably very difficult to diagnose and fix. That's why it got through the beta process without being found, because it's a tough one to begin with. For perspective, let me describe the worst bug that Microsoft Access ever had. In an Access form, there's a method for navigating between records that uses what are called "bookmarks," which are pointers to cursor locations in a recordset. Forms have two sets of bookmarks, one in the recordset loaded in the form, and one in an exact duplicate of that recordset, called the RecordsetClone. The RecordsetClone allows you to find out things about the real recordset without having an effect on the real recordset. The method for navigation via recordset is that you do a FindFirst in the recordsetclone. If there's a match, it sets the bookmark to the new record position. Since the form's real recordset is identical, you can set it equal to the RecordsetClone's bookmark, which then moves the form's cursor location to the same place as it was in the RecordsetClone. So far so good. This feature had been implemented sometime around Access version 1.x and 2.0, if I'm remembering correctly (i.e., in 1993 or so), and had been relied on by all Access programmers (as well as by some of the wizards built into Access that write code for you to accomplish tasks, like finding a record). But in August of 1998, it was announced that a bug had been found with bookmark navigation that could cause data to be written to the wrong record. The bug manifested itself in these circumstances: 1. in a form having a recordset with more than 262 records 2. that has had a record deleted from it 3. that then has an edit to a record that is after record 262 and after the deleted record And the result was that changes to any of the remaining undeleted records *after* the deleted record got written to the record *after* what the form displayed. The problem was that the recordsetclone and the form's actual recordset were out of synch with each other because of the deleted record. The workaround was actually very simple -- after deleting a record, requery the form (if you don't requery you keep the same number of records with the deleted record display #deleted in all fields). But the problem existed back to all versions of Access since 1993. For more than five years people had been using the product and nobody had identified this extremely serious bug. By the time I heard about it, it had already been diagnosed and the workaround discovered. Microsoft issued a service release about a month later that fixed the problem permanently. As it turns out, one of my applications probably was bitten by this bug in early 1998 (users reported remembering entering data into particular records, then coming back to the same record and not seeing it there; we never could identify the cause, though it may have been the bookmark bug; reports of the bookmark bug also caused me to discover that bookmark navigation had problems when activated on unsaved records because under some circumstances the data would *not* be saved and no error would be raised). But because the symptoms were so incredibly hard to diagnose (who is going to recognize that the data in a record actually belongs to a different record?), and because the scenario required for it to happen was so specific (though not at all uncommon). Microsoft is a much, much larger company than MakeMusic, and Access has orders of magnitude more users than Finale, but it took FIVE YEARS for the bug to actually be discovered, even though it had the potential to badly corrupt the data of any application that was exposed to the bug (i.e., using bookmark navigation and allowing deletes without requery in a form with more than 262 records). It may take MakeMusic quite a while to fix this bug. I'm not at all surprised that a fix did not make it into release 2006a, since that was surely already "gold" by the time this bug popped up a few weeks ago. Indeed, it wouldn't at all surprise me if this bug were actually at an extremely low level, in the interaction between Finale and the underlying database engine. It also wouldn't surprise me if this is a bug in the database engine, and that the old temp file code already including bug fixes that worked around the problem, and when the old temp file code was replaced with the new, the bug fixes were also discarded. This is one of the reasons Netscape failed when it discarded their codebase and started over, because however bad and disorganized that codebase was, it included many years worth of fixes and workarounds for bugs and special sitations, and when it was discarded, all of that had to be recreated. The only question for me would be exactly why it didn't pop up during beta testing. But, again, beta testing only works flawlessly when all scenarios are testing and, for whatever reason, the scenario that produces this bug was simply not part of the beta testing process. It's incredibly hard to beta test systematically, since you simply can't anticipate every scenario that could be a problem. I'd say we should hold off on the criticism until was see the fix and get some information about how the bug happened. It may be that it should have been found before release. It could also be that it's related to some outside software, and indeed, it could be something released *after* Finale's beta testing ended is to blame (such as some minor upgrade or add-in for OS X). Any programmer can tell you that these things are *very* difficult. And I'd bet that nobody feels any worse than the Finale development team, not even those of you who've lost months of work to the bug. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
