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