Currently there is little danger in not locking the record. The OS is not multitasking, so no other program should be attempting to access it at the same time (there are, however, hacks, DAs & other such exceptions to be considered).
Once a real multitasking OS becomes available, record locking will be much more important. May as well write your code the right way now, and avoid pain later. -- -Richard M. Hartman [EMAIL PROTECTED] 186,000 mi/sec: not just a good idea, it's the LAW! "Danny Epstein" <[EMAIL PROTECTED]> wrote in message news:89795@palm-dev-forum... > > > It seems like a bad idea, but > > what are the implications of modifying a db record that was > > accessed via DmQueryRecord versus DmGetRecord? > > I agree, in general. However, ISTR that some of our example code does this. > > > I was surprised to discover that I can actually modify > > a record that was accessed with DmQueryRecord, > > and I'm wondering in what situations this is actually ok, > > since DmQueryRecord is much faster than DmGetRecord. > > Yup. The OS doesn't enforce the rule that records must be marked busy before > being modified. The APIs for modifying a record's contents take a pointer to > the record contents rather than a record number. This would make it > difficult to verify that the busy bit is set without support from the memory > manager. > > In general, if you're going to modify a record, you probably want to set the > dirty bit. Passing true to DmReleaseRecord is a convenient way to do this. > > My take on it is that the busy bit is primarily used to prevent programming > errors. I generally use DmGetRecord if I'm going to modify a record. I've > made exceptions when building abstraction layers where it's inconvenient to > distinguish between reading and writing. > -- > Danny @ PalmSource > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
