Hmmm. Often list layouts let users delete multiple checked rows, so that's definitely possible from a UI point of view. That's also the reason for wanting to know how many rows were deleted, so you can say "47 endangered species deleted" in a msg to the user.
Re DAO vs something else, I'm new to the split between a DAO and a DG, so I need some education on the division between them. Is the idea that a DAO always deals w exactly one row, and a DG w rowsets? Delete can *act* on multiple rows, but doesn't *return* a rowset, so where does it go? Someplace besides DAO and DG? > How would you know if all requested rows were > deleted or not? re-query? How about the number of rows deleted (which @@ROWCOUNT can tell you, in SQL anyway), vs number of items in the list of pks to delete? Personally, I think what the user *really* wants to know is if the rows they chose to delete are gone. If some couldn't be deleted for some reason, they should be told. If someone else deleted half of them while they had their list open, that doesn't matter much; long as they're gone, all is good. Users may have a passing curiosity about how many their action killed, but that's an app-vibe kind of thing. A shopping cart probably doesn't need to say how many items you just removed, but a medical research app may well want to say how many patients you just took out of a followup study. On further thought, given those UI requirements, my theory is that data components should: a) throw an error on real failure (can't find the db...) b) report any rows that couldn't be deleted (unless that should get thrown too; I wouldn't think so) c) report how many were deleted; the calling code can use that info or not, depending on the situation. Since (b) is most likely a descriptive string, (c) has to be a string too. The weakness here is that if the deletion is in response to a machine-generated request (web service etc), you don't want the requestor to have to parse the result string to know if there was a failure that should effect future actions. In that light, returning a struct with msg and success_bool (false only if some requested rows couldn't be deleted) might make sense. A GUI may use the msg, other client services may use the bool, or both. Make sense? Dave Merrill ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
