シッククライアントコンポーネントとシンクライアントコンポーネントの両方を使用してアプリを開発しています。また、スキーマの変更によって独自のバージョン番号が生成され、変更スクリプトを適用できるように、データベースをバージョン管理します。ただし、データベースの変更は、シッククライアントの変更と歩調を合わせて行われるとは限りません。はい、今日のデータベースの変更により、シッククライアントに列が追加されてが必要になる場合がありますが、明日のデータベースの変更により、外部の変更を必要としないストアドプロシージャのエラーが修正される場合があります。下位互換性のあるものと互換性のないものがある場合に、特定のデータベースバージョンと互換性があるかどうかをテストするためにシッククライアントをコーディングするにはどうすればよいですか？
誰もが気にかけているとしても、私たちのアプリはSQL Serverと統合された.NETアプリですが、これはプラットフォームの質問というよりもバージョン管理の質問のようです。プラットフォーム固有のソリューションがない限り...
たとえば、テーブルを作成できます。2つの文字列列を持つメタデータ、およびスキーマの現在のバージョンのエントリ（または複数のエントリ）をそこに配置します。あなたは今、似たようなことをしていると思います。
そして、バージョンを2つの数値に分割します（メジャー/マイナースキームなど）。後方互換性のない方法でスキーマを変更すると、メジャーバージョンが増加します。下位互換性のある変更の後、マイナーバージョンを更新するだけです。
Majorは、アプリが現在のスキーマと互換性があるかどうかを確認するために使用され、major + minorは、スキーマを更新できるかどうかを確認するために使用されます。
これはほとんどのアプリケーションで使用されているソリューションだと思います。
メジャー/マイナーバージョン番号スキームを採用できますか？
メジャー番号の変更は、クライアントが更新する必要があることを意味し、マイナー番号の変更は更新する必要がありません。
これらのいずれかを使用すると、バージョン番号は常に増加しています。
データベースが必要な最小クライアントバージョンを知っていて、クライアントが必要な最小データベースバージョンを知っている場合、アップグレードが必要なもの（ある場合）を判断するための簡単なチェックです-ロジックをストアドプロシージャにカプセル化するか、コード、それはあなたの決定です...