> 現行ではユーザーが既存のデータを編集している間は常にロックがかかるようになっています。
> このようにデータをロックする時間がユーザーの操作により長時間におよぶ可能性がある場合、
> やはりSQL Serverのロックに頼らず上記の方法で、アプリ側で独自に制御するしかないのでしょうか。
> むしろこれが正当なやり方なのでしょうか。
データ占有時間が長いならサーバへの負担を掛けないためにも止むをえないと思います。
クライアントプログラムがロック状態を戻す前にダウンしてしまった場合の復旧手段さえ
用意しておけばいいと思います。

>整合性を問題としているなら、トランザクション処理でまとめ、
>接続が切れたらロールバックとすべきでは？
ロック～更新にトランザクションをかけています。
接続が切れたら自動的にトランザクションはロールバックされロックは解除されますよね？
接続が切れてもトランザクションやロックを維持することはできるんですか？

>また、在庫引き当てとかである処理ですが、
>単純に長時間編集中であることを維持したいなら、データとして
>編集中の情報を書き込んでおけばいいだけでは？
編集中であるという情報をデータとして書き込むというのは私も考えていました。
ただ、なにか他にスマートな方法はないものかと相談させていただきました。

現行ではユーザーが既存のデータを編集している間は常にロックがかかるようになっています。
このようにデータをロックする時間がユーザーの操作により長時間におよぶ可能性がある場合、
やはりSQL Serverのロックに頼らず上記の方法で、アプリ側で独自に制御するしかないのでしょうか。
むしろこれが正当なやり方なのでしょうか。

ロックでどうにかしようという考え方がそもそも間違っていると
思います。ロックの時間は出来るだけ短くなるようにすべきです。
接続が切れてもロックが維持されるということは、再度同じデータを
同じユーザが編集に来るという保証が必要です。接続が切れたから
新規データで入力しなおすと、ロックされたゴミデータがどんどん
溜まっていきます。その問題に対する対策も必要になります。

整合性を問題としているなら、トランザクション処理でまとめ、
接続が切れたらロールバックとすべきでは？

また、在庫引き当てとかである処理ですが、
単純に長時間編集中であることを維持したいなら、データとして
編集中の情報を書き込んでおけばいいだけでは？
もちろん、編集中のまま放置のデータができますので、管理者が
編集中を解除するか、一定時間で解除できるような対策機能が必要
となるのは変わりませんが。

データベースアプリでのSQL Serverとの接続とロックのタイミングなどについてなのですが、
通常データを取得する際にはその都度接続→取得→切断とするか、
既に接続済みのコネクションを使用して（切断されていれば再接続してから）取得、という方法をとっています。

データのロックを必要としない更新については、データ取得と同様に上記の流れで処理を行っていますが、
ロックが必要な場合はデータの編集中はロックを維持していなければならないので同様にはいきません。

ロック中に接続が切れてしまった場合に、なにかしらの対応はできるものでしょうか。
または別の方法でロックをかける、ロックをかけたと同様の動きをさせるなどはできるでしょうか。