I know some people get a kick out of running the KILL command. Heck, I'm sure all of us enjoy stopping a runaway process from an annoying user at times. But not everyone seems to understand exactly how databases work. It's not necessarily a knock on the original poster, after all, most of us had to learn about the ACID properties at some point. Perhaps even after someone dropped a database in our lap without warning.

If you kill a spid, I saw some confusion about data loss in a recent thread. You won't lose data, but you could still have a problem. It's not a technical problem and the storage engine inside SQL Server ensures that the transaction conforms to the ACID properties to ensure data integrity.

The users, however, might or might not realize that their "work" was not done. It depends on the error handling of your application, what message (if any) that is presented to the user, and if they're even still around. I've seen people start processes they expected to run long and then leave their workstation. If there wasn't a message on it later, they might assume the transaction had gone through.

Even if you tell them you're killing the process, they might still think that some amount of work is completed. There are all sorts of users, with all different kinds of expectations out there, so you should be sure that they understand exactly what is happening.

And be sure that they know their "work" is lost. From the point of view of someone doing data entry, if the transaction rolls back and the application can't handle it, they will have to enter information again. So their work is essentially lost.

Those of us in technology sometimes forget the impact of our systems in the real world. Even when things work well or as designed, they may still be a problem for real people that have real tasks to get done.