我正在启动一个新项目，我们希望将基于桌面的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数据库。