2 部分访问网络表格由 2 人填写

发布于 2025-01-02 16:16:51 字数 280 浏览 0 评论 0原文

我用 php 和 mysql 做了类似的东西。只是想知道这是否可以在 MS Access 中完成,然后在 SharePoint 上使用。

表格包含 A 部分和 B 部分。填写表格的人员将填写 A 部分并点击完成。第二个人将收到表格已开始填写的通知,并将获得 A 部分已填写的表格,并将填写 B 部分。填写 A 部分的人看不到 B 部分,因此看起来好像他们正在完整填写表格。填写 B 部分的人员可以看到为 A 部分输入的值,但无法编辑它们。

这可以在 MS Access 中完成并在 SharePoint 上使用吗?

I have made something just like this using php and mysql. Just curious to know if this can be done in MS Access and then used on SharePoint.

Form has section A and B. Person to start the form will fill out section A and hit complete. Second person will be notified that the form has been started and will be given the form with Section A complete and will fill out Section B. The person who fills Section A cannot see Section B so it appears as though they are completely filling out the form. The person filling out Section B can see the values entered for Section A but cannot edit them.

Can this be done in MS Access and used on SharePoint?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

苄①跕圉湢 2025-01-09 16:16:51

我不明白为什么不。但是,当您说“表单”时,它并不是真正允许您编辑表中所有记录的典型 Access 表单。

Access 客户端上的通用表单或 Access Web 上的通用表单的工作方式并没有完全不同。

事实上,对于用户 A 来说,如果他们不需要 B 部分,那么只需让他们启动/加载一个没有 B 部分的表单即可。

这里的问题与其说是形式,不如说是安全问题、身份验证问题,您计划使用什么手段来限制一个用户相对于另一个用户的能力。

Access Web 服务基于 SharePoint。我没有对此进行测试,但我确实相信您可以将行权限解析为单个用户。

因此,构建基本表单并防止一个用户打开另一个表单非常容易。因此,您只需让第二个人根据许可启动不同的表单即可。

然而,由于 Access 将表单绑定到表的性质,真正的问题变成了安全性的细节。

我确实不能说 Access 是传递需要填写和传递的“表单”的理想工具。 InfoPath + SharePoint 更适合公司中的此类工作流程。

因此,访问表单是附加在数据表上的东西。此类表格不应被视为传递的“表格”。因此,Access Web 中的表单与 FoxPro、VB6 甚至常规客户端 Access 应用程序中构建的表单非常相似。

因此,当涉及到构建用户需要在 Access 中内置的典型应用程序类型中编辑数据的表单时,这种易用性和快速开发模型现在包括 Access 将这些应用程序发布到网站的能力。

因此,您构建的应用程序的性质在这里并没有真正改变太多,只是现在我们为使用 Access 构建的那些典型表单类型提供了 Web 选择。

I don't see why not. However, when you say form, that not really a typical Access form that lets you edit all records in a table.

How a general form on the Access client side or that of on Access web works is not a whole bit different.

In fact, for user A, if they don't need the part B, then just have them launch/load a form that does not have part B anyway.

The issue(s) here are not so much the form, but issues of security, authentication what means you plan to use to restrict one user's ability over that of another.

Access web services are based on SharePoint. I not tested this, but I do believe that you can resolve row permissions down to individual users.

So building the basic form and certainly preventing one user from opening anther form is quite easy. So you just have the second person launch a different form based on permission.

However, due to the nature of Access being bound forms to tables, the real issue becomes the finer details of security.

I cannot really say that Access is the ideal tool for passing "forms" that are to be filled out and passed around. InfoPath + SharePoint are far more designed for such a type of workflow in a company.

So an access form is something attached to a table of data. Such forms should not be considered a "form" that is passed around. So forms in Access web are very similar to forms built in FoxPro, VB6, or even those in regular client Access applications.

So when it comes down to building forms that users need to edit data in typical type of application built in Access, then that ease of use and rapid development model now includes the ability of Access to publish those applications to a Web site.

So the nature of the applications you build has not really changed a lot here, It just now that we have a web choice for those typical types of forms built using Access.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文