我开发了一个包含胖客户端和瘦客户端组件的应用程序。我们还对数据库进行版本控制，以便架构更改产生它们自己的版本号，并且可以应用更改脚本。但是，数据库更改并不总是与胖客户端更改同步进行。是的，今天的数据库更改可能会添加一列并需要在胖客户端中添加一个列，但明天的数据库更改可能会修复不需要任何外部更改的存储过程中的错误。当有些向后兼容而有些不兼容时，我如何对胖客户端进行编码以测试它是否与特定的数据库版本兼容？
即使有人关心，我们的应用程序也是与 SQL Server 集成的 .NET 应用程序，但这似乎更像是版本控制问题而不是平台问题。除非有特定于平台的解决方案...
您可以创建一个表，例如。具有两个字符串列的元数据，并在其中放置一个具有当前模式版本的条目（或多个条目）。我想你现在也在做类似的事情。
并将版本拆分为两个数字（如主要/次要方案）。当您以非向后兼容的方式更改架构时，您将增加主要版本。向后兼容更改后，您只需更新次要版本。
主要用于应用程序检查它是否与当前架构兼容，主要+次要用于检查您是否可以/需要更新架构。
我认为这是大多数应用程序使用的解决方案。
你能采用主要/次要版本号方案吗？
主编号的更改意味着客户端需要更新，而次编号的更改则不需要。
对于其中任何一个，版本号总是在增加。
如果数据库知道它需要的最低客户端版本，并且客户端知道它需要的最低数据库版本，那么这是一个简单的检查来确定需要升级的内容（如果有的话）——现在是你将逻辑封装在存储过程中，还是在代码，这是你的决定......