Powerbuilder 10.5：升级还是迁移？
Powerbuilder 10.5: upgrade or migrate away?
我们最近开始支持 PowerBuilder 10.5 应用程序，问题来了我们是否应该考虑替代方案或将应用程序 运行 保留在 PB 10.5.经典的PB应用；基于 Oracle 数据库构建的管理软件。
目前，该应用运行良好，但我们重新考虑的原因有两个：
- 此应用的唯一开发人员即将退休。他是唯一一个
谁拥有支持此应用程序的所有 PB 知识。
- 我们可能想要改进应用程序提供的服务。因此与其他工具的集成指日可待。
我不是很熟悉PB，但是我看过它（只有最新的版本）现在被Appeon支持了。最新版本现在是 2017 R3，即将推出 2019 版本。
我想知道尝试将当前 10.5 版本更新到最新版本的利弊是什么。 是否值得更新？或者坚持使用 10.5 版本的优缺点是什么？
或者我们应该考虑转向更新的技术，因为现在很少有人能找到 Powerbuilder 了？如果是这样，您会推荐什么技术？
不仅仅是 differences between the older and newer PB 版本，我正在寻找 upgrade/migrate/do 什么都没有的动机。
谢谢。
因此，没有明确的答案，但我们可以就非技术要点提出一些想法（根据要求）。
留在 10.5："if it ain't broke, don't fix it." 有很多话要说 如果它有效并且您对它的作用感到满意，请不要移动它。
但是，既然您已经说过您打算推进它，您可能要考虑 10.5 不支持当前的操作系统（一年内，Windows 当前支持的系统MS 将只有 Win8 和 Win10），当 10.5 出来时，这只是想象中的虚构。您的 10.5 应用程序现在可以在 Win10 上运行，但这完全是因为 MS 在应用程序的向后兼容性方面的工作，并且您没有利用 PB 中在 Windows 的未来版本中存在问题的区域。如果您需要添加功能，使用至少表明它可以在您的操作系统上运行的版本可能会有所帮助。
数据库的并行参数，例外情况是如果您的应用程序使用 SQL Anywhere，数据库过去在多个 PB 包中免费提供。现在您必须单独购买。
关于尝试继续使用旧版本的任何东西，要记住的一件事是支持。如果您遇到困难，供应商基本上不会与您交谈，而且同行社区一直在缩小，因此您与其他开发人员进行对话的机会越来越少。
升级：升级通常是一项小工作。我见过的最常见的例外原因是：弃用的功能，以及依赖于版本之间不一致的行为的编码（一些行为承诺保持一致，但不是全部）。 运行 与您的 PB 专家一起使用试用版进行迁移测试，以解决该问题 table。
升级时要记住的一件事是许可模式已经改变。 PB以前有永久模式（一次购买，永远使用），但现在是订阅模式。这是否对您有所改善，由您自行判断。
是否"worth it"升级，在我看来通常归结为
- OS支持
- 数据库支持
- 供应商支持
- 同伴支持
- 弃用的功能，以及我是否使用它们
- 新功能，以及我是否会使用它们（您要求我们不要讨论最后两项，无论如何都需要非常单独地权衡，并且在 Appeon 的网站上有详细记录）
"Migrating"：我把 "migrating" 放在引号中，因为我不相信有一种技术可以让你 "migrate"在代码翻译的意义上。 （我会让你读一读我的一篇 old tirades 关于想 "migrate" 关闭 PB。）我在这里要讲的是 重写 新技术.从旧的 PB 系统中提取业务规则和在另一种技术中 redesigning/rewriting 都是一项巨大的努力。
最近支持的最大论点是获得并留住 PowerBuilder 人才。让拥有 PB 的人成为他们的腰带是困难的，并且判断合法人才具有挑战性，即使面试的人是你这边的 PB table。 （如果您想继续使用 PB，请利用您即将退休的人。）培训具有 PB 的人也不是一件容易的事。有人曾经问我，而不是教育工作者，我是否可以在一周内设计一门课程并培训他的团队。我笑了。在由当时的供应商 Powersoft 的专业教育工作者设计和教授的为期两周的课程之后，我回到家并编写了令人难以置信的令人尴尬的代码。我还需要大量时间练习，并从同龄人那里获得反馈。如果你可以找人或培训某人，如果他们每年只做几周的 PB 工作，那么那些 PB "muscles" 将会萎缩。不管 PB 与其他东西的技术争论如何，如果你不能让 PB 人才来维护它，PB 就是死胡同。
恐怕我不是建议替代技术的人。过去，就富客户端应用程序而言，选择 Microsoft 不会出错，但从那时起，MS 已向开发社区派遣了一些徒劳的追逐者，这些追逐最终以弃用的技术告终。我不想成为展望未来的人。
祝你好运。
Terry 的回答非常好，但关于 PowerBuilder 2019 中的新功能的迁移问题没有得到解决。
PowerBuilder 2019 的一个主要功能是 C# DataStore（与 .NET Core 兼容）和 DataWindow 对象迁移实用程序。 C# DataStore 具有与 PowerScript DataStore 相同的 API 和事务机制。 Appeon 网站上有详细记录：https://www.appeon.com/support/documents/appeon_online_help/powerbuilder/api_reference/PowerBuilder.Data/DataStore/IDataStore/IDataStore.html
如果您决定选择 C#，PowerBuilder 2019 的这一功能使迁移工作成为 PowerScript 非可视化代码的 "port" 而不是重写（出于上述原因）。
这是示例 PowerScript 代码：
public function datastore of_retrieve (date ad_start, date ad_end, decimal adec_amt);
Datastore lds
lds = Create Datastore
lds.dataobject = "d_order_customer"
lds.SetTransObject(SQLCA)
lds.Retrieve(ad_start, ad_end, adec_amt)
Return lds
end function
下面是在 C# 中使用 C# DataStore 的相同示例：
public IDataStore GetOrderCustomerInfo(DateTime startDate, DateTime endDate, decimal amount)
{
IDataStore dataStore = new DataStore("d_order_customer", _context);
dataStore.Retrieve(startDate, endDate, amount);
return dataStore;
}
我建议迁移。
您会发现有几家公司提供迁移到 java 和 .net 的领先平台。
对我来说 UI 目前唯一的选择是网络。使用其他技术没有多大意义。
如果您的公司使用大量 MS 堆栈，例如 MS OS、SQL 服务器。 Exchange、Sharepoint 等我建议迁移到 C#，否则迁移到 Java 更有意义
我们最近开始支持 PowerBuilder 10.5 应用程序，问题来了我们是否应该考虑替代方案或将应用程序 运行 保留在 PB 10.5.经典的PB应用；基于 Oracle 数据库构建的管理软件。
目前，该应用运行良好，但我们重新考虑的原因有两个：
- 此应用的唯一开发人员即将退休。他是唯一一个 谁拥有支持此应用程序的所有 PB 知识。
- 我们可能想要改进应用程序提供的服务。因此与其他工具的集成指日可待。
我不是很熟悉PB，但是我看过它（只有最新的版本）现在被Appeon支持了。最新版本现在是 2017 R3，即将推出 2019 版本。
我想知道尝试将当前 10.5 版本更新到最新版本的利弊是什么。 是否值得更新？或者坚持使用 10.5 版本的优缺点是什么？
或者我们应该考虑转向更新的技术，因为现在很少有人能找到 Powerbuilder 了？如果是这样，您会推荐什么技术？
不仅仅是 differences between the older and newer PB 版本，我正在寻找 upgrade/migrate/do 什么都没有的动机。
谢谢。
因此，没有明确的答案，但我们可以就非技术要点提出一些想法（根据要求）。
留在 10.5："if it ain't broke, don't fix it." 有很多话要说 如果它有效并且您对它的作用感到满意，请不要移动它。
但是，既然您已经说过您打算推进它，您可能要考虑 10.5 不支持当前的操作系统（一年内，Windows 当前支持的系统MS 将只有 Win8 和 Win10），当 10.5 出来时，这只是想象中的虚构。您的 10.5 应用程序现在可以在 Win10 上运行，但这完全是因为 MS 在应用程序的向后兼容性方面的工作，并且您没有利用 PB 中在 Windows 的未来版本中存在问题的区域。如果您需要添加功能，使用至少表明它可以在您的操作系统上运行的版本可能会有所帮助。
数据库的并行参数，例外情况是如果您的应用程序使用 SQL Anywhere，数据库过去在多个 PB 包中免费提供。现在您必须单独购买。
关于尝试继续使用旧版本的任何东西，要记住的一件事是支持。如果您遇到困难，供应商基本上不会与您交谈，而且同行社区一直在缩小，因此您与其他开发人员进行对话的机会越来越少。
升级：升级通常是一项小工作。我见过的最常见的例外原因是：弃用的功能，以及依赖于版本之间不一致的行为的编码（一些行为承诺保持一致，但不是全部）。 运行 与您的 PB 专家一起使用试用版进行迁移测试，以解决该问题 table。
升级时要记住的一件事是许可模式已经改变。 PB以前有永久模式（一次购买，永远使用），但现在是订阅模式。这是否对您有所改善，由您自行判断。
是否"worth it"升级，在我看来通常归结为
- OS支持
- 数据库支持
- 供应商支持
- 同伴支持
- 弃用的功能，以及我是否使用它们
- 新功能，以及我是否会使用它们（您要求我们不要讨论最后两项，无论如何都需要非常单独地权衡，并且在 Appeon 的网站上有详细记录）
"Migrating"：我把 "migrating" 放在引号中，因为我不相信有一种技术可以让你 "migrate"在代码翻译的意义上。 （我会让你读一读我的一篇 old tirades 关于想 "migrate" 关闭 PB。）我在这里要讲的是 重写 新技术.从旧的 PB 系统中提取业务规则和在另一种技术中 redesigning/rewriting 都是一项巨大的努力。
最近支持的最大论点是获得并留住 PowerBuilder 人才。让拥有 PB 的人成为他们的腰带是困难的，并且判断合法人才具有挑战性，即使面试的人是你这边的 PB table。 （如果您想继续使用 PB，请利用您即将退休的人。）培训具有 PB 的人也不是一件容易的事。有人曾经问我，而不是教育工作者，我是否可以在一周内设计一门课程并培训他的团队。我笑了。在由当时的供应商 Powersoft 的专业教育工作者设计和教授的为期两周的课程之后，我回到家并编写了令人难以置信的令人尴尬的代码。我还需要大量时间练习，并从同龄人那里获得反馈。如果你可以找人或培训某人，如果他们每年只做几周的 PB 工作，那么那些 PB "muscles" 将会萎缩。不管 PB 与其他东西的技术争论如何，如果你不能让 PB 人才来维护它，PB 就是死胡同。
恐怕我不是建议替代技术的人。过去，就富客户端应用程序而言，选择 Microsoft 不会出错，但从那时起，MS 已向开发社区派遣了一些徒劳的追逐者，这些追逐最终以弃用的技术告终。我不想成为展望未来的人。
祝你好运。
Terry 的回答非常好，但关于 PowerBuilder 2019 中的新功能的迁移问题没有得到解决。
PowerBuilder 2019 的一个主要功能是 C# DataStore（与 .NET Core 兼容）和 DataWindow 对象迁移实用程序。 C# DataStore 具有与 PowerScript DataStore 相同的 API 和事务机制。 Appeon 网站上有详细记录：https://www.appeon.com/support/documents/appeon_online_help/powerbuilder/api_reference/PowerBuilder.Data/DataStore/IDataStore/IDataStore.html
如果您决定选择 C#，PowerBuilder 2019 的这一功能使迁移工作成为 PowerScript 非可视化代码的 "port" 而不是重写（出于上述原因）。
这是示例 PowerScript 代码：
public function datastore of_retrieve (date ad_start, date ad_end, decimal adec_amt);
Datastore lds
lds = Create Datastore
lds.dataobject = "d_order_customer"
lds.SetTransObject(SQLCA)
lds.Retrieve(ad_start, ad_end, adec_amt)
Return lds
end function
下面是在 C# 中使用 C# DataStore 的相同示例：
public IDataStore GetOrderCustomerInfo(DateTime startDate, DateTime endDate, decimal amount)
{
IDataStore dataStore = new DataStore("d_order_customer", _context);
dataStore.Retrieve(startDate, endDate, amount);
return dataStore;
}
我建议迁移。 您会发现有几家公司提供迁移到 java 和 .net 的领先平台。 对我来说 UI 目前唯一的选择是网络。使用其他技术没有多大意义。 如果您的公司使用大量 MS 堆栈，例如 MS OS、SQL 服务器。 Exchange、Sharepoint 等我建议迁移到 C#，否则迁移到 Java 更有意义