Has anybody any experience in using Gupta (formerly Centura) Team Developer?
有没有人使用Gupta(以前的Centura)团队开发人员?
If so, what do you think of it in terms of its capability to support the development of mature, scalable, maintainable applications?
如果是这样,您对支持开发成熟,可扩展,可维护的应用程序的能力有何看法?
Thanks
4 个解决方案
#1
I have been using the CTD since version 1.1. Currently I'm still using 2.1 PTF4, mainly for doing rich client CRUDs under windows 98-Vista against Centura SQLBase, MS Sql Server or MS Access. I have not upgraded from 2.1 to the newer versions, so I can only talk about the relatively old 2.1 from 2001.(§)
我从1.1版开始就使用CTD。目前我还在使用2.1 PTF4,主要用于在Windows 98-Vista下针对Centura SQLBase,MS Sql Server或MS Access进行富客户端CRUD。我没有从2.1升级到更新版本,所以我只能谈谈2001年相对较旧的2.1。(§)
Our applications typically have about 150 form windows, make heavy use of classes (still called "user defined variables" in 2.1) and integrate MS Office. We have no stability issues or memory leaks. The development environment is a bit long in the tooth, though: no intellisense, no smart debugging and practically unusable without a mouse. This may have changed with newer versions.
我们的应用程序通常有大约150个窗体窗口,大量使用类(在2.1中仍称为“用户定义变量”)并集成MS Office。我们没有稳定性问题或内存泄漏。然而,开发环境有点长,没有智能感知,没有智能调试,没有鼠标几乎无法使用。对于较新的版本,这可能已经改变。
There is nothing in the nature of CTD that forces you to write un-maintainable code. Using classes and file-includes you can have a good degree of reusability in your code if you designed your code to be reusable, that is. A problem for maintainability may be that CTDs variables and classes do not have access modifiers like "private" or "protected". Also: no interfaces or abstract classes. On the other hand: multiple inheritance.
CTD的本质没有任何东西迫使您编写不可维护的代码。如果您将代码设计为可重用的,那么使用类和文件包含代码可以在代码中具有良好的可重用性。可维护性的问题可能是CTD变量和类没有“私有”或“受保护”等访问修饰符。另外:没有接口或抽象类。另一方面:多重继承。
The "outline structure" of the code takes some getting used to, but I even sometimes miss the outline structure when I get lost in a sprawling C#-file with variable declarations and event handlers all over the place...
代码的“大纲结构”需要一些时间来习惯,但是当我迷失在一个庞大的C#文件中时,我甚至有时会错过大纲结构,其中包含变量声明和事件处理程序......
The controls for 2.1 where pretty complete but we still had to manually integrate "modern" things like toolbars, datepickers or tab-controls. OTOH it even has a numerical input field out of the box. One of the Unify-Newsletters stated that they added a lot of eye-candy, to let the apps look more up-to-date. The mtable-Extensions for table windows where very helpfull, available here: MTable by MICSTO . Integrating 3rd-party-DLLs (e.g. for integrating a smartcard-reader) is not really fun, especially when they use structs. Oh: and the "Centura Report Builder" is a royal pain in the derierre.
2.1的控件非常完整但我们仍然必须手动集成“现代”的东西,如工具栏,日期选择器或制表符控件。 OTOH它甚至还有一个开箱即用的数字输入字段。其中一个Unify-Newsletters表示,为了让应用看起来更新,它们增添了许多吸引人的眼球。桌面窗口的mtable-Extensions非常有用,可在此处获得:MICSTO的MTable。集成第三方DLL(例如,用于集成智能卡读卡器)并不是很有趣,特别是当它们使用结构时。哦:“Centura Report Builder”是derierre的皇室痛苦。
A big pro is the SDK that shipps with the CTD: this makes it very easy to integrate self written tools into the development environment, e.g. for code generation.
一个重要的专业人员是与CTD交流的SDK:这使得将自编写工具集成到开发环境中变得非常容易,例如:用于代码生成。
Bottom line: We used and still use CTD for scalable and maintainable apps. The learning curve can be a bit steep because of the unusual outline structure and can lead the unwary towards writing "ugly" code: e.g. lots of static functions, lots of code in the "Message Actions" and problems with variable scoping. I think your success with CTD will depend on the nature of the application you want to write: for a rich client CRUD you might almost certainly be better off than with .net, for a web app I honestly don't know.
结论:我们使用并仍然使用CTD来实现可扩展和可维护的应用程序。由于不寻常的轮廓结构,学习曲线可能有点陡峭,并且可能导致不小心写出“丑陋”的代码:例如:许多静态函数,“消息操作”中的大量代码以及变量作用域的问题。我认为你在CTD方面取得的成功将取决于你想要编写的应用程序的性质:对于一个富客户端CRUD,你几乎肯定会比使用.net更好,对于一个我真的不知道的网络应用程序。
Keep in mind that all this relates to the 8 year old 2.1 version of CTD. Things may be radically different now. If you can, get an evaluation version.
请记住,所有这些都与8年前的2.1版CTD有关。现在情况可能完全不同。如果可以,请获得评估版。
Edit: Aside from the pros and cons of the language alone, you might want to consider that CTD is a niche. There are not many free tools and I have yet to find a vibrant community (there was a newsgroup, but the server went down after the merger - maybe its still around somwhere). So, googling up help on specific Problems may no be easy.
编辑:除了语言的优点和缺点之外,您可能还想考虑CTD是一个利基。没有太多的免费工具,我还没有找到一个充满活力的社区(有一个新闻组,但服务器在合并后关闭 - 也许它仍然在somwhere)。因此,在特定问题上搜索帮助可能并不容易。
(§) I did not continue the upgrade path from 2.1 to 5.1 because after the merge with Unify they wanted to make patches available only for subscribers to their support scheme (called GLS). Since I was not going to pay for bugfixes I deceided to continue using 2.1 for our legacy apps and switch to .net for new apps. I think they revised this later on.
(§)我没有继续从2.1升级到5.1的升级路径,因为在与Unify合并之后,他们希望仅为其支持方案(称为GLS)的订户提供补丁。由于我不打算为错误修正付费,所以我决定继续为我们的旧应用程序使用2.1并切换到.net以获取新应用程序。我想他们稍后会对此进行修改。
#2
I have been working with Team Developer (formerly Centura Builder, SQL Windows, etc.) for 9 years. IMO things have not changed too much from the version 2.1 which Stephan Keller described in his comprehensive answer.
我已经与Team Developer(以前的Centura Builder,SQL Windows等)合作了9年。 IMO的事情并没有像Stephan Keller在他的综合答案中描述的2.1版那样发生太大的变化。
The company I am working for is currently using TD version 5.1 and considering upgrade to TD 5.2 next year. We are developing a business software product, run against Oracle database. The application has more than 500 form windows and several hundred reports.
我工作的公司目前正在使用TD版本5.1,并考虑明年升级到TD 5.2。我们正在开发一个针对Oracle数据库运行的商业软件产品。该应用程序有超过500个窗体窗口和数百个报告。
I think Team Developer scales well to both simple small applications, and larger enterprise application suites with big RDBMS and hundreds of users.
我认为Team Developer可以很好地适应简单的小型应用程序,以及具有大型RDBMS和数百个用户的大型企业应用程序套件。
The code outline makes the IDE easy to approach and I think the learning curve will not be that steep. The code editing is possible even without mouse, since there is a number of handy keyboard shortcuts. Of course the window designer needs mouse. There is also a built-in Active Coding Assistant in the newer releases.
代码大纲使IDE易于接近,我认为学习曲线不会那么陡峭。即使没有鼠标也可以进行代码编辑,因为有许多方便的键盘快捷键。窗户设计师当然需要鼠标。在较新的版本中还有一个内置的Active Coding Assistant。
The newest releases (5.1 and 5.2) offer some new GUI controls, such as a date/time picker, a grid window (enhancement to the widely used table window) and Rich Text editor. There is also a new tab control. Menus can be shown ribbon-like, though this is not a "real" ribbon bar. Sample screenshots can be found on the Unify web site.
最新版本(5.1和5.2)提供了一些新的GUI控件,例如日期/时间选择器,网格窗口(对广泛使用的表窗口的增强)和富文本编辑器。还有一个新的选项卡控件。菜单可以显示为带状,但这不是“真正的”带状条。可以在Unify网站上找到示例截图。
Also new GUI themes were introduced in the 5.x versions of TD, to provide a more modern look and feel for the applications.
在5.x版本的TD中还引入了新的GUI主题,以便为应用程序提供更现代的外观和感觉。
There have been a number of stability issues, performance problems and problems with screen painting etc. with the 5.x versions of TD. The older 3.x and 4.x are known of very robust quality, having only a very limited number, if any, stability or other issues. These issues are discussed actively on the Unify Support Forum. Many of these issues are related to database routers (Oracle, MS SQL Server) or Windows API calls. The basic functionality of TD is usually working quite fine.
使用5.x版本的TD存在许多稳定性问题,性能问题和屏幕绘画等问题。已知较旧的3.x和4.x具有非常强大的质量,仅具有非常有限的数量(如果有的话)稳定性或其他问题。在统一支持论坛上积极讨论这些问题。其中许多问题与数据库路由器(Oracle,MS SQL Server)或Windows API调用有关。 TD的基本功能通常很好。
Also help on specific problems and questions can be reached on the Support Forum. The developer community is maybe small, but quite active.
还可以在支持论坛上获得有关具体问题和问题的帮助。开发者社区可能很小,但非常活跃。
#3
My Company uses Team Developer for years successfully (most of our Applications are written in 2.0, with some in 5.2 as Web-Applications) and there are plans to change our development to version 6.0.
我的公司成功使用Team Developer多年(我们的大多数应用程序都是用2.0编写的,有些在5.2中用作Web应用程序),并且计划将我们的开发改为6.0版。
Coming from a C++ background I first had to find the way into the language (I still miss some features like encapsulation, well-structured error handling1 or scoping of variables2)
来自C ++背景我首先必须找到进入语言的方式(我仍然会遗漏一些功能,如封装,结构良好的错误处理1或变量2的范围)
But after all, I learned to live with the limitation of the language and with some discipline our applications are relatively easy to maintain. (as a note: We have a set of base applications working together and use the same codebase with some customer-related variations to build individual versions for every customer - bugfixes appear at the common codebase (and is used afterwards for any other project), special modifications at the lokal project files). You just need to set up some basic guidelines for your projects and keep with them as the compiler wouldn't enforce them.
但毕竟,我学会了忍受语言的限制,并且通过一些规则,我们的应用程序相对容易维护。 (作为注释:我们有一组基本应用程序协同工作,并使用相同的代码库和一些客户相关的变体为每个客户构建单独的版本 - 错误修正出现在公共代码库中(之后用于任何其他项目), lokal项目文件的特殊修改)。您只需要为项目设置一些基本指导原则并与它们保持一致,因为编译器不会强制执行它们。
1 You could catch a sql error only at the point it occurs or globally for the whole program.
1您只能在它发生时或整个程序全局捕获sql错误。
2 I still sometimes get cases where a mis-spelled variable compiles for something in a completely independent window - or compiler errors for semi-referenced handles sharing the same name but different data types
2我有时会得到错误拼写的变量在完全独立的窗口中编译某些内容的情况 - 或者是半共享句柄的共享同名但不同数据类型的编译器错误
#4
We used TD for several large apps but due to the lack of resources, the obsolete SAL language and aged runtime we have migrated millions of lines of SAL code and several thousand forms to C# and Visual Studio 2010 using ice tea group gupta/unify migration tool.
我们将TD用于几个大型应用程序,但由于缺乏资源,过时的SAL语言和老化的运行时,我们使用冰茶组gupta / unify迁移工具将数百万行SAL代码和数千种表单迁移到C#和Visual Studio 2010 。
We were skeptical at first. But now we have brand new apps, fully integrated with our other .NET assetts with a small fraction of the time needed for a rewrite. And we didn't have to try to understand what all that all code was doing. :) the conversion was nearly perfect!
起初我们持怀疑态度。但现在我们拥有全新的应用程序,与我们的其他.NET资产完全集成,只需要一小部分时间进行重写。而且我们不必试图了解所有代码所做的事情。 :)转换几近完美!
Forgot to mention that we automatically converted over 1200 report builder reports to crystal reports .NET saving probably a century of boring work.
忘了提到我们自动将超过1200个报告生成器报告转换为水晶报告.NET可能会节省一个世纪的无聊工作。
#1
I have been using the CTD since version 1.1. Currently I'm still using 2.1 PTF4, mainly for doing rich client CRUDs under windows 98-Vista against Centura SQLBase, MS Sql Server or MS Access. I have not upgraded from 2.1 to the newer versions, so I can only talk about the relatively old 2.1 from 2001.(§)
我从1.1版开始就使用CTD。目前我还在使用2.1 PTF4,主要用于在Windows 98-Vista下针对Centura SQLBase,MS Sql Server或MS Access进行富客户端CRUD。我没有从2.1升级到更新版本,所以我只能谈谈2001年相对较旧的2.1。(§)
Our applications typically have about 150 form windows, make heavy use of classes (still called "user defined variables" in 2.1) and integrate MS Office. We have no stability issues or memory leaks. The development environment is a bit long in the tooth, though: no intellisense, no smart debugging and practically unusable without a mouse. This may have changed with newer versions.
我们的应用程序通常有大约150个窗体窗口,大量使用类(在2.1中仍称为“用户定义变量”)并集成MS Office。我们没有稳定性问题或内存泄漏。然而,开发环境有点长,没有智能感知,没有智能调试,没有鼠标几乎无法使用。对于较新的版本,这可能已经改变。
There is nothing in the nature of CTD that forces you to write un-maintainable code. Using classes and file-includes you can have a good degree of reusability in your code if you designed your code to be reusable, that is. A problem for maintainability may be that CTDs variables and classes do not have access modifiers like "private" or "protected". Also: no interfaces or abstract classes. On the other hand: multiple inheritance.
CTD的本质没有任何东西迫使您编写不可维护的代码。如果您将代码设计为可重用的,那么使用类和文件包含代码可以在代码中具有良好的可重用性。可维护性的问题可能是CTD变量和类没有“私有”或“受保护”等访问修饰符。另外:没有接口或抽象类。另一方面:多重继承。
The "outline structure" of the code takes some getting used to, but I even sometimes miss the outline structure when I get lost in a sprawling C#-file with variable declarations and event handlers all over the place...
代码的“大纲结构”需要一些时间来习惯,但是当我迷失在一个庞大的C#文件中时,我甚至有时会错过大纲结构,其中包含变量声明和事件处理程序......
The controls for 2.1 where pretty complete but we still had to manually integrate "modern" things like toolbars, datepickers or tab-controls. OTOH it even has a numerical input field out of the box. One of the Unify-Newsletters stated that they added a lot of eye-candy, to let the apps look more up-to-date. The mtable-Extensions for table windows where very helpfull, available here: MTable by MICSTO . Integrating 3rd-party-DLLs (e.g. for integrating a smartcard-reader) is not really fun, especially when they use structs. Oh: and the "Centura Report Builder" is a royal pain in the derierre.
2.1的控件非常完整但我们仍然必须手动集成“现代”的东西,如工具栏,日期选择器或制表符控件。 OTOH它甚至还有一个开箱即用的数字输入字段。其中一个Unify-Newsletters表示,为了让应用看起来更新,它们增添了许多吸引人的眼球。桌面窗口的mtable-Extensions非常有用,可在此处获得:MICSTO的MTable。集成第三方DLL(例如,用于集成智能卡读卡器)并不是很有趣,特别是当它们使用结构时。哦:“Centura Report Builder”是derierre的皇室痛苦。
A big pro is the SDK that shipps with the CTD: this makes it very easy to integrate self written tools into the development environment, e.g. for code generation.
一个重要的专业人员是与CTD交流的SDK:这使得将自编写工具集成到开发环境中变得非常容易,例如:用于代码生成。
Bottom line: We used and still use CTD for scalable and maintainable apps. The learning curve can be a bit steep because of the unusual outline structure and can lead the unwary towards writing "ugly" code: e.g. lots of static functions, lots of code in the "Message Actions" and problems with variable scoping. I think your success with CTD will depend on the nature of the application you want to write: for a rich client CRUD you might almost certainly be better off than with .net, for a web app I honestly don't know.
结论:我们使用并仍然使用CTD来实现可扩展和可维护的应用程序。由于不寻常的轮廓结构,学习曲线可能有点陡峭,并且可能导致不小心写出“丑陋”的代码:例如:许多静态函数,“消息操作”中的大量代码以及变量作用域的问题。我认为你在CTD方面取得的成功将取决于你想要编写的应用程序的性质:对于一个富客户端CRUD,你几乎肯定会比使用.net更好,对于一个我真的不知道的网络应用程序。
Keep in mind that all this relates to the 8 year old 2.1 version of CTD. Things may be radically different now. If you can, get an evaluation version.
请记住,所有这些都与8年前的2.1版CTD有关。现在情况可能完全不同。如果可以,请获得评估版。
Edit: Aside from the pros and cons of the language alone, you might want to consider that CTD is a niche. There are not many free tools and I have yet to find a vibrant community (there was a newsgroup, but the server went down after the merger - maybe its still around somwhere). So, googling up help on specific Problems may no be easy.
编辑:除了语言的优点和缺点之外,您可能还想考虑CTD是一个利基。没有太多的免费工具,我还没有找到一个充满活力的社区(有一个新闻组,但服务器在合并后关闭 - 也许它仍然在somwhere)。因此,在特定问题上搜索帮助可能并不容易。
(§) I did not continue the upgrade path from 2.1 to 5.1 because after the merge with Unify they wanted to make patches available only for subscribers to their support scheme (called GLS). Since I was not going to pay for bugfixes I deceided to continue using 2.1 for our legacy apps and switch to .net for new apps. I think they revised this later on.
(§)我没有继续从2.1升级到5.1的升级路径,因为在与Unify合并之后,他们希望仅为其支持方案(称为GLS)的订户提供补丁。由于我不打算为错误修正付费,所以我决定继续为我们的旧应用程序使用2.1并切换到.net以获取新应用程序。我想他们稍后会对此进行修改。
#2
I have been working with Team Developer (formerly Centura Builder, SQL Windows, etc.) for 9 years. IMO things have not changed too much from the version 2.1 which Stephan Keller described in his comprehensive answer.
我已经与Team Developer(以前的Centura Builder,SQL Windows等)合作了9年。 IMO的事情并没有像Stephan Keller在他的综合答案中描述的2.1版那样发生太大的变化。
The company I am working for is currently using TD version 5.1 and considering upgrade to TD 5.2 next year. We are developing a business software product, run against Oracle database. The application has more than 500 form windows and several hundred reports.
我工作的公司目前正在使用TD版本5.1,并考虑明年升级到TD 5.2。我们正在开发一个针对Oracle数据库运行的商业软件产品。该应用程序有超过500个窗体窗口和数百个报告。
I think Team Developer scales well to both simple small applications, and larger enterprise application suites with big RDBMS and hundreds of users.
我认为Team Developer可以很好地适应简单的小型应用程序,以及具有大型RDBMS和数百个用户的大型企业应用程序套件。
The code outline makes the IDE easy to approach and I think the learning curve will not be that steep. The code editing is possible even without mouse, since there is a number of handy keyboard shortcuts. Of course the window designer needs mouse. There is also a built-in Active Coding Assistant in the newer releases.
代码大纲使IDE易于接近,我认为学习曲线不会那么陡峭。即使没有鼠标也可以进行代码编辑,因为有许多方便的键盘快捷键。窗户设计师当然需要鼠标。在较新的版本中还有一个内置的Active Coding Assistant。
The newest releases (5.1 and 5.2) offer some new GUI controls, such as a date/time picker, a grid window (enhancement to the widely used table window) and Rich Text editor. There is also a new tab control. Menus can be shown ribbon-like, though this is not a "real" ribbon bar. Sample screenshots can be found on the Unify web site.
最新版本(5.1和5.2)提供了一些新的GUI控件,例如日期/时间选择器,网格窗口(对广泛使用的表窗口的增强)和富文本编辑器。还有一个新的选项卡控件。菜单可以显示为带状,但这不是“真正的”带状条。可以在Unify网站上找到示例截图。
Also new GUI themes were introduced in the 5.x versions of TD, to provide a more modern look and feel for the applications.
在5.x版本的TD中还引入了新的GUI主题,以便为应用程序提供更现代的外观和感觉。
There have been a number of stability issues, performance problems and problems with screen painting etc. with the 5.x versions of TD. The older 3.x and 4.x are known of very robust quality, having only a very limited number, if any, stability or other issues. These issues are discussed actively on the Unify Support Forum. Many of these issues are related to database routers (Oracle, MS SQL Server) or Windows API calls. The basic functionality of TD is usually working quite fine.
使用5.x版本的TD存在许多稳定性问题,性能问题和屏幕绘画等问题。已知较旧的3.x和4.x具有非常强大的质量,仅具有非常有限的数量(如果有的话)稳定性或其他问题。在统一支持论坛上积极讨论这些问题。其中许多问题与数据库路由器(Oracle,MS SQL Server)或Windows API调用有关。 TD的基本功能通常很好。
Also help on specific problems and questions can be reached on the Support Forum. The developer community is maybe small, but quite active.
还可以在支持论坛上获得有关具体问题和问题的帮助。开发者社区可能很小,但非常活跃。
#3
My Company uses Team Developer for years successfully (most of our Applications are written in 2.0, with some in 5.2 as Web-Applications) and there are plans to change our development to version 6.0.
我的公司成功使用Team Developer多年(我们的大多数应用程序都是用2.0编写的,有些在5.2中用作Web应用程序),并且计划将我们的开发改为6.0版。
Coming from a C++ background I first had to find the way into the language (I still miss some features like encapsulation, well-structured error handling1 or scoping of variables2)
来自C ++背景我首先必须找到进入语言的方式(我仍然会遗漏一些功能,如封装,结构良好的错误处理1或变量2的范围)
But after all, I learned to live with the limitation of the language and with some discipline our applications are relatively easy to maintain. (as a note: We have a set of base applications working together and use the same codebase with some customer-related variations to build individual versions for every customer - bugfixes appear at the common codebase (and is used afterwards for any other project), special modifications at the lokal project files). You just need to set up some basic guidelines for your projects and keep with them as the compiler wouldn't enforce them.
但毕竟,我学会了忍受语言的限制,并且通过一些规则,我们的应用程序相对容易维护。 (作为注释:我们有一组基本应用程序协同工作,并使用相同的代码库和一些客户相关的变体为每个客户构建单独的版本 - 错误修正出现在公共代码库中(之后用于任何其他项目), lokal项目文件的特殊修改)。您只需要为项目设置一些基本指导原则并与它们保持一致,因为编译器不会强制执行它们。
1 You could catch a sql error only at the point it occurs or globally for the whole program.
1您只能在它发生时或整个程序全局捕获sql错误。
2 I still sometimes get cases where a mis-spelled variable compiles for something in a completely independent window - or compiler errors for semi-referenced handles sharing the same name but different data types
2我有时会得到错误拼写的变量在完全独立的窗口中编译某些内容的情况 - 或者是半共享句柄的共享同名但不同数据类型的编译器错误
#4
We used TD for several large apps but due to the lack of resources, the obsolete SAL language and aged runtime we have migrated millions of lines of SAL code and several thousand forms to C# and Visual Studio 2010 using ice tea group gupta/unify migration tool.
我们将TD用于几个大型应用程序,但由于缺乏资源,过时的SAL语言和老化的运行时,我们使用冰茶组gupta / unify迁移工具将数百万行SAL代码和数千种表单迁移到C#和Visual Studio 2010 。
We were skeptical at first. But now we have brand new apps, fully integrated with our other .NET assetts with a small fraction of the time needed for a rewrite. And we didn't have to try to understand what all that all code was doing. :) the conversion was nearly perfect!
起初我们持怀疑态度。但现在我们拥有全新的应用程序,与我们的其他.NET资产完全集成,只需要一小部分时间进行重写。而且我们不必试图了解所有代码所做的事情。 :)转换几近完美!
Forgot to mention that we automatically converted over 1200 report builder reports to crystal reports .NET saving probably a century of boring work.
忘了提到我们自动将超过1200个报告生成器报告转换为水晶报告.NET可能会节省一个世纪的无聊工作。