带有触摸屏 POS 界面的 Access 2007 是转换我的 INFORMIX-SQL 应用程序的正确选择吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（1）
我怀疑如果你问 Foxpro 开发人员，他们会告诉你这是最好的选择工具。
我确信如果您询问 filemaker 开发人员，他们会告诉您选择他们的工具。
问题在于，在大多数情况下，如果您询问访问开发人员，该开发人员也会回答“是”。
我很难想象您上面提到的所有上述工具，它们都具有在屏幕上显示多个表格中的信息的能力。这几乎是当今任何开发系统的要求。简而言之，您确实在这里问了错误的问题。
我不认为问题是他们是否有能力显示多个表中的信息。他们都可以做到这一点。也许一个公平的问题是每个产品需要多少工作以及将这些多个表分割在一起的效果如何？
在 Access 中，您可以在窗体上放置文本框和控件，并且为了显示相关数据，您可以放置一个称为子窗体控件的控件。这种方法允许您对这种经典的典型主表与子记录关系进行建模，并且无需编写一行代码。
当然，您不限于一对多，但您实际上可以并排插入两个子表单，并进行一对多，然后让第二个子表单控件显示第二个表中的更多记录。
这是我的意思的屏幕截图：
在上面，您在顶部有一个主要记录，其中包含有关捐赠日期的信息和事件。左侧有一个人员列表及其捐赠金额（一对多）。
然后在右侧，对于每个人，您将捐款金额分为多个帐户。 （当金额不平衡时，绿色框显示红色）。
因此，上述内容产生了一个经典的会计问题，从 Quickbooks 一直到高端会计包，几乎每个会计包从第一天将资金分配到多个帐户时都会遇到这个问题。
上面的表单中的代码很少，大部分的关系和设置以及子记录的过滤和显示都是由access自动处理的。
因此，归根结底，我几乎认为您上面提到的所有产品都能够建模和开发这些类型的屏幕。而且，它们都会带来与您现在所拥有的相对相似的屏幕和用户体验。
当然，我偏向于访问，我相信我可以更快、更快地构建像上面这样的屏幕，并且比您提到的大多数其他产品更少麻烦、更少的代码和工作量。
然而，归根结底，您使用并找到合适的平台和工具肯定不会以一个问题和一个概念为中心，您需要在一个表单上为多个表显示多条信息。如前所述，这适用于任何现代开发系统，包括基于 Web 的开发系统。
其他考虑因素和因素是您需要什么类型的报告和输出？您是否需要他的专栏报告，或者您是否需要将发票样式的表格类型报告发送到预打印发票表格的打印机。我认为这些问题比你当前的问题更大。
这里真正的问题不是任何现代开发系统都可以在一个表单上显示多条数据，它们都可以。这里真正的因素和问题是您需要软件在哪些平台、硬件要求和系统上运行？
那么问题是某些位置是否会有多个用户？某些位置是否需要安全备份或某种类型的加密？您计划如何发布错误修复并更新到该软件的下一个伟大版本？
其他问题是您将有多少开发人员致力于此工作。您将使用哪种软件分发方式。您需要什么样的支持基础设施来为客户提供支持和安装软件。因此，这个列表一直在不断地出现，所有这些问题都让关于在一个表单上显示多条信息的能力的问题显得相形见绌。
除了上述所有问题之外，您还需要考虑自己在软件开发方面的培训和技能。要真正掌握任何软件开发系统，都需要投入大量自己的时间来学习。虽然我认为 access 是一个非常好的 RAD（快速应用程序开发）工具，但实际上我会说 access 的学习曲线比 VB6 的学习曲线要大得多。
选择一个平台就像一场婚姻，你必须投入大量的时间（几个月，甚至几年）来真正学习并熟练使用这样的系统开发软件。
如果您要使用一组新工具，则需要考虑以下技能组列表**：
永远不要尝试与由第 3 阶段或更低级别的人员组成的团队一起进行项目。 （**** Page-Jones, Meilir。“软件工程专业知识的七个阶段”，《美国程序员》，1990 年 7 月至 8 月）。
因此，您不能直接使用新工具并期望精通开发复杂的应用程序。我这里有一篇关于将遗留应用程序转换为 ms access 的文章。
本文中有一些重要的教训：
关于将选择（多值数据库）应用程序转换为关系数据库系统的注释。
http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000003。 html
无论您选择哪个平台，祝您好运。
I suspect if you ask Foxpro developer, they would tell you that's the best tool of choice.
And I'm sure if you ask a filemaker developer, they would tell you to choose their tool.
So much of the question is, for the most part if you ask an access developer, that developer would also answer yes.
I would be hard pressed to imagine that all of the above tools you mentioned above, all of them have the capability of displaying information from more than one table in a screen. That's pretty much a requirement for any development system today. So in a nutshell, you're really asking the wrong question here.
I don't think the question is do they have the capability of displaying information from more than one table. They all can do this. Perhaps a fair question would be how much work and how well does each product slice and dice together these multiple tables?
In access you place text boxes and controls on a form, and to display related data, you can you place a control called a sub-form control. This approach allows you to model this classic can typical master to child record table relationship, and do so without having to write one line of code.
And of course you're not limited to one to many, but you can actually insert two sub forms side by side, and have a one to many, and in turn have the 2nd sub form control display many more records from that second table.
Here's a screen shot of what I mean:
In above you have one main record at the top with information about donation date and event. On the left you have a list of people and their donation amount (one to many).
Then on the right side, for each person, you have the donation amount split out into multiple accounts. (and the green box shows red when the amounts don't balance).
So, the above creates that classic accounting problem that just about every accounting package from Quickbooks all the way up to hi end accounting packages have done from day one when splitting out funds to multiple accounts.
The above form has very little code in it, and most of the relationships and setups and filtering and displaying of the child records is all handled automatically by access.
So at the end of the day, I'm pretty much of the view that all of products you mention above are capable of modeling and developing these types of screens. And, they all will result in an screen and user experience that would be relatively similar to what you have now.
Now course I'm a biased towards access, and I believe that I can build screens like the above quicker, faster, and with less hassle less code and effort than most of the other products you mentioned .
However, at the end of the day what platform and tools you use and find as appropriate is certainly not going to be centered around the ONE QUESTION and ONE CONCEPT that you have need to display multiple pieces of information on a form for multiple tables. As mentioned, this is gonna be given for any modern development system, including web based development systems.
Other considerations and factors is what type of reports, and outputs to you need? Do you need his column are reports, or do you need to send an invoice style forms type report to a printer that's preprinted invoice forms. I think these are bigger questions then your current question.
The real question here's not can any modern development system display multiple pieces of data on a form, they all can. The REAL factors and issues here are what platforms, hardware requirements, and systems do you need the software to run on?
So the issue is will some of the locations have multiple users? Will some of the locations need secure backup or some type of encryption? How do you plan to issue bug fixes, and updates to the next great version of the software?
Other issues are how many developers will you have working on this. What kind of distribution method will you use for the software. What kind of support infrastructure will you have to give customers support and installing the software. So, this list goes on and on and all these issues dwarf the question about the ability to display multiple pieces of information on one form.
In addition to all of the above issues, you need to consider your own training and skill set in development of software. To really master any software development system, you need to invest a considerable amount of your own time to learn. While I think the access is a very good RAD (rapid application development) tool, I will actually say that access has a considerably larger learning curve then say that of VB6 for example.
Choosing a platform is very much like a marriage, you have to invest enormous amounts of your time (months, and even years) to really learn and become proficient at developing software with such a system .
If you're jumping into a new set of tools, then the following list of skill sets needs to be taken into consideration **:
One should NEVER attempt a project with a team consisting with Stage 3 or lower people. (**** Page-Jones, Meilir. "The Seven Stages of Expertise in Software Engineering", American Programmer, July-Aug 1990).
So you just can't jump into a new tool and expect to be proficient at developing complex applications. I have an article here about converting a legacy application into ms access .
There are some great lessons in this article:
Notes on Conversion of a Pick (Multi-Value database) Application to a Relational database system.
http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000003.html
Good luck in whichever platform you choose.