Lotus Smartsuite 带来“更新的东西”
我将尝试让我的场景尽可能简短、切中要点。
我目前工作的办公室在 Windows 98 / XP 上使用 Lotus Smartsuite，使用大量 Lotus Script 将 Lotus 123 和 Lotus Word Pro 文档结合在一起。他们还大量使用 Lotus 对象链接功能。我将在下面描述它的行为：
您可以用大量数据填充 123 电子表格中的行和列，以您喜欢的任何方式设置样式和格式，并将其定义为范围（这里没有什么独特之处）。但是，您可以复制该范围并将其作为链接粘贴到 Lotus Word Pro 文档中。然后，此链接按其范围名称进行分类，因此将范围扩展回 123 文件中会导致 Word Pro 文档中的表格扩展。此链接还包含 123 电子表格中单元格的所有格式和样式。我想您现在已经知道，此链接是完全实时的，您可以双击对象中的任何位置，它会打开 123 文件进行编辑，并且所有更改都会在两个文档之间前后移动。从测试设备检索到的大部分数据都存储在这 123 个电子表格中，然后将其中的部分数据链接到发送给客户的最终 Lotus Word Pro 报告文档中。
注意：需要明确的是，这与 Open Office 中的 DDE 链接不同，后者似乎允许复制未定义的单元格范围并将其导入到所有格式都丢失的文档中并进行编辑来回并不是直截了当的。它的行为也与 OLE 对象不同，OLE 对象似乎只导入整个电子表格而不是其中的一小部分。
然而，近年来，支持这种较旧的软件 (Lotus) 变得越来越困难，特别是在以下方面向客户发送文档（Lotus word Pro 文件通常不受更现代的 Office 工具的支持），并且 Lotus Smartsuite 的技术支持现在似乎几乎不存在。此外，由于担心主流 IT 技术人员不再采用脚本语言进行持续开发，持续的开发和支持似乎是徒劳的。一旦编写它的人转向其他事情，我们将留下意大利面条脚本，其语言无人能帮助我们。
因此，我们的目标是在年底前实现 IT 系统的“现代化”。 Linux 也正在成为一个非常可行的选择（毫无疑问是 Debian 或其衍生版本），但 Open Office 似乎不具备上述链接功能。这种链接如此重要的原因是因为办公室的资深人士非常习惯这种工作方式 - 将数据存储在电子表格中，稍后在他们的 Word Pro 文档中链接回它，等等。我认为他们非常热衷于保留这种做法仍在继续，我们在现代办公工具中没有发现类似的做法（按照我的要求）。我可以看到，作为一名软件工程师（精通多种语言），这种做法并不是使用和存储数据的最安全或最好的方式（数据库浮现在脑海中），但我想知道是否有人可以给我一些其他好的方法为什么这在工作场所是不好的做法的原因（我一直相信你应该让你的数据远离你的报告和格式，两者永远不应该交织在一起 - 这对我来说就像电子表格地狱）......或者为什么这是一件值得继续做的好事！？
因此，对于那些仍然和我在一起的人，我想我要问的是：
这种存储数据、在电子表格中格式化数据并在 Word 文档之间直接来回导入数据的做法是好是坏，以及可以做什么？做完了吗？我想我需要证明我的观点，以防万一。
对于 Linux 或 Windows，是否有任何现代的替代方法可以替代这种链接方法（无论天气如何，这种做法是好是坏）？此链接必须包含格式以及动态范围大小（DDE 链接似乎不是答案）。
如果您必须从头开始，您的解决方案是什么？将所有内容存储在数据库中并使用 SQL 简单地在 Word 文档中查询所需的数据？你会怎么做？您会使用什么软件？
对于这种情况的任何帮助都会非常有帮助，或者如果您知道我应该去哪里寻求建议，那也将不胜感激。
感谢您的阅读！
I shall try and keep my scenario as brief as possible and to the point.
The office I’m currently working for uses Lotus Smartsuite on Windows 98 / XP, using lots of Lotus Script to tie together Lotus 123 and Lotus Word Pro documents. They also make heavy use of the Lotus Object Linking functions. I shall describe its behaviour below:
You can fill rows and columns in a 123 Spreadsheet with data galore, style it and format it any way you like and define it as a range (nothing unique here). However, you can then copy that range and paste it as a link in a Lotus Word Pro document. This link is then categorised by its range name, so expanding the range back in the 123 file causes the table in the Word Pro Document to expand. This link also carries with it all the formatting and styling of the cells in the 123 Spreadsheet. As I imagine you are now aware, this link is completely live, you can double click anywhere in the object and it opens up the 123 file for editing, and all changes go backward and forward between the two documents. Most of the data retrieved from testing equipment is stored in these 123 spreadsheets and then parts of that are linked into a final Lotus Word Pro report document sent to the customer.
Note: Just to be clear, this is NOT the same as a DDE link in Open Office, which seems to allow for copying of a non-defined range of cells to be imported into a document where all formatting is lost and editing back and forth is not straight forward. It also behaves differently to an OLE object, which seems to only import the entire Spreadsheet rather than a small subsection of it.
However, in recent years, support this older software (Lotus) is becoming more difficult, especially with regards to sending customers documents (Lotus word Pro files are generally unsupported by more modern Office Tools) and technical support for Lotus Smartsuite seems to be practically non-existent these days. Also, with the fear of on going development in a scripting language no-longer being practised by mainstream IT technicians, on-going development and support seems futile. Once the guys who wrote it move on to other things, we will be left with spaghetti script in a language nobody can help us with.
So, we have this goal of "modernising" our IT system by the end of the year. Linux is becoming a very viable option too (No doubt Debian or a derivative), but Open Office doesn't seem to have the linking capability mentioned above. The reason this linking is so important is because the veterans of the office are so used to working this way - storing data in the spreadsheet, linking back to it later in their Word Pro documents, etc. I think they are more than keen to keep this practice going and we have found no equivalent of it in modern office tools (as was requested of me). I can see, as a software engineer (fluent in many languages), how this practice is not the safest or best way of using and storing data (databases spring to mind), but I was wondering if someone could give me a few other good reasons as to why this is bad practice in the work place (I was always in the belief that you should keep your data away from your reporting and formatting, the two should never be entwined - this looks like spreadsheet hell to me) ... or why this is a good thing to keep doing!?
So, for those of you still with me, I guess what I am asking is:
Is this practice of storing data, formatting it in spreadsheets and importing that directly back and forth between word documents good or bad, and what can be done about it? I guess I'll need to prove my point in case either way for this.
Are there ANY modern alternatives to this linking method (regardless of weather it is good or bad practice or not) out there for Linux or Windows? This link MUST carry formatting as well as dynamic range sizes (DDE links don't seem to be the answer).
What would your solution be if you had to start from scratch? Store everything in databases and use SQL to simply ask for the data you need in your word documents? How would you do this? What software would you use?
Any help with this scenario would be more than helpful, or if you know anywhere I should go to ask for advice, that would be appreciated too.
Thank-you for reading!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的建议是先退后一步。现在的做事方式有什么好处？这只是一个很难改掉的习惯吗？是否有任何原因需要按原样维护和链接文档和电子表格，或者这只是一个要求，因为“以前就是这样做的”？
如果您可以删除该要求，那么您就有更多选择，并且您正在构建一个更易于理解和维护的系统。
关于问题1，我认为将数据存储在电子表格中没有什么问题，特别是当最终用户需要创建和维护它们并且开发人员有限时。一些问题是这些数据是否需要保护、电子表格之间是否相关、在整个公司范围内重复，或者是否应该以更好的方式在整个公司范围内共享。如果其中任何一个是正确的，那么集中式数据库就会更有意义。就我个人而言，我希望将任何有价值的数据安全地存储在数据库中，以便对其进行管理、访问可以控制、可以轻松备份等。
关于问题 2，您可以 在 Microsoft Office 中执行相同的操作。您可以链接文档，以便数据保留在源 Excel 文档中但显示在 Word 文档中，也可以将 Excel 电子表格嵌入到 Word 文档中。
您可能需要使用 Microsoft Access 来存储数据和生成报告。或者，您可以使用关系数据库后端和报告前端构建应用程序。可能性是广阔的。这实际上取决于公司内部的专业知识所在。
如果是我，我可能会使用 SQL Express 后端（免费）和自定义 ASP.NET MVC 应用程序来生成报告，但这正是我的专业知识所在。
My suggestion is to first take a step back. What is the benefit to the way things are done now? Is it just a habit that is tough to break? Is there any reason the documents and spreadsheets need to be maintained and linked the way they are, or is it just a requirement because 'that's how it was done before'?
If you can remove that requirement, you have a lot more options and you're building a system that's easier to understand and maintain.
Regarding question 1, I believe there's nothing wrong with storing data in spreadsheets, especially if the end-users need to create and maintain them and development staff is limited. Some questions are whether that data needs to be secured, is related between spreadsheets, is duplicated across the company, or should be shared in a better way across the company. If any of those are true then a centralized database would make more sense. Personally I'd want any valuable data safely stored in a database where it can be managed, access to it can be controlled, it can be easily backed-up, etc.
Regarding question 2, you can do the same thing in Microsoft Office. You can either link the documents, so that the data stays in the source excel doc but appears in the word doc, or you can embed the excel spreadsheet within the word doc.
You might want to look at Microsoft Access for storing the data and generating reports. Or you could build an application using a relational database back-end and reporting front-end. The possibilities are wide-open. It really depends on where the expertise lies within the company.
If it were me I'd probably use a SQL Express back-end (it's free) and a custom ASP.NET MVC application for generating the reports, but that's just where my expertise lies.