我正在启动一个新项目,我们希望将基于桌面的Access 2016应用程序(具有大量后端VBA和表之间的关系)迁移到内部部署的SharePoint 2016中,并很快迁移到SharePoint Online。据我所知,我们将获得对SharePoint网站的网站权限,我们可以使用它进行任何操作。我希望通过SharePoint 2016本地部署并最终使SharePoint Online联机,这意味着我可以迁移Access后端表和查询的SQL Server和Azure SQL数据库,因为我知道SharePoint列表将不足以满足此要求,尽管错误的观念是SharePoint列表可以替代数据库表。
我关心的是如何构建自定义表单,执行所需的业务逻辑,执行CRUD操作以及如何以Excel文件的形式将数据从SharePoint网站上传到后端。
我是SharePoint的新手,并且由于它不支持VBA,Microsoft今年早些时候停止了Access Web Apps的使用,并且他们正在淘汰SharePoint Designer 2013和InfoPath,所以过去一周的一些研究表明,我是最佳选择正在使用ASP.NET Core构建自定义Web应用程序,并以某种方式将其部署到我们可以控制的SharePoint网站和子网站,或者开发了大量HTML,CSS和JS来创建前端界面。我已经阅读了有关Business Connectivity Service的信息,该服务用于从SharePoint网站前端和数据库后端获取数据或将数据发布到SharePoint网站前端和DB后端,以及如何使用Javascript和AJAX调用在数据库与前端之间进行CRUD操作。我调查了PowerApps,但这些似乎还不够用,我仍在尝试区分SharePoint Web部件和SharePoint加载项。
以上任何一项甚至是可行的选择吗?有人可以通过更好的途径解决这个问题吗?我最需要什么技术来解决这个问题?
答案 0 :(得分:0)
支持将表从Access移到SharePoint仍然是一个选择。
因此,您的所有VBA代码等都将像以前一样工作。唯一真正的问题是,是否要代替使用SQL Server将数据移至SharePoint表。
SQL Server表比SharePoint表快得多。
但是,您当然可以考虑将表移动到SharePoint。当您将表移动到SharePoint(或SQL Server)时,然后访问代码,表单,报表等,甚至您的VBA代码都将像以前一样工作。这意味着您将继续将Access应用程序部署到每个桌面。唯一的区别是现在您的表位于SharePoint或SQL Server上。
以上选择不会导致基于Web的应用程序。
因此您可以移动数据,但是您的应用程序将仍然是桌面应用程序。
如果您希望构建基于Web的应用程序,则Access是错误的工具–您需要采用Visual Studio之类的东西。
因此,您可以继续使用Access,并将数据表放入云或现场SharePoint中-但该应用程序仍将基于桌面。
答案 1 :(得分:0)
在过去的几年中,我广泛使用了以下内容,对此感到满意:
是的,PowerApps有缺点,但是有很多现实的解决方法,并且会定期添加新功能/改进。
我还使用SharePoint列表作为数据源,但是几乎总是将其迁移到Azure SQL数据库。