> Well, whether one deals with it in the SQL statement, whether one does > it with the tools Matt Robertson designed, whether one does not deal with > it at all. It's a question of preference. But since it's a database > problem, and SQL is the unique way the programmer deals with the > database, I don't see why it couldn't be done through this mean.
It's not a database problem! If all your users were, in fact, directly connected to the database, you could easily tell the database what kind of results you wanted, and leave it up to the database to figure out how to make that happen. But your users are not connected to the database. Instead, they periodically send messages to your application, which in turn sends responses to them. This makes it your application's problem, since your application is acting as a proxy for the actual users. Traditional approaches to locking will not get you very far, here. > By the way, apparently it is already implemented anyway, except with > Access datasources. I'm not sure what you mean by this. Row-level locking? How does that help you when you need multiple transactions to manage a single user interaction? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:252609 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
