“独立” SQL Server 的补充

发布于 2024-11-26 15:04:41 字数 838 浏览 0 评论 0原文

我运行一个内部应用程序,使用 Visual Studio 2008 进行编程,并使用 SQL Server 2008 作为后端。除了服务器之外,我的用户还要求能够将数据存储在独立文件中。引用的原因包括:

  • 远离办公室或旅行,有时到其他国家
  • 我们在多个城市设有办事处,其中一些没有 SQL Server
  • 需要制作“非官方”数据副本,用于备份、正在进行的工作、备用场景、向其他办公室发送电子邮件等

我应该如何实施?出于可维护性的考虑,理想的解决方案是一个独立的数据库,不需要重复或重写数据访问代码。只需设置连接字符串即可。

这样的事有可能吗?我认为最接近的是 SSCE,但我的理解是它缺乏某些功能,例如视图、过程等。因此,如果任何数据访问代码使用此类对象,那么它不会延续到独立数据库。

目前,我使用 MS Access 作为我的独立数据库选项(因为这是内部的,所以所有用户都将拥有 Office)。到目前为止,我已经成功地完成了这项工作,没有太大的麻烦,但我想知道 Access 和 Sql Server 从根本上来说是两种不同的动物已经有多久了。

如前所述,目前该程序在 VS2008 中,但很快我希望升级到 VS2010 并开始使用实体框架(如果这有帮助的话)。

编辑:
嗯,从下面的两个回复来看,SSCE 似乎是标准选择。但它并不是一个完美的复制品,因为正如前面提到的,它缺乏完整 SS 的几个功能。我明白为什么,因为对于小型本地数据库来说,这些功能可能不是必需的。但是,对于数据访问层最初是为 Sql Server 编码的应用程序,似乎至少有可能需要替代代码。

在每个用户的计算机上安装 SSExpress 可能是保留 SS 功能的一种方法,但考虑到我们的设置,我对此犹豫不决。

I run an in-house application, programmed with visual studio 2008, that uses SQL Server 2008 as the back end. In addition to the server, my users have demanded the ability to store data in independent files. The reasons cited include:

  • away from office or traveling, sometimes to other countries
  • we have offices in several cities, some of which do not have a sql server
  • the need to make "unofficial" copies of data, for backup, work in progress, alternate scenarios, email to other offices, etc

How should I implement this? The ideal solution, in the interest of maintainability, would be a standalone database that requires no duplication or rewriting of the data access code. Simply set the connection string and off you go.

Is such a thing even possible? I suppose the closest relative is SSCE, but my understanding is that it lacks certain features such as views, procs, etc. So if any data access code utilizes such objects, then it wouldn't carry over for the standalone db.

Currently, I am using MS Access as my standalone db option (since this is in-house all users will have Office). So far I have managed to make this work without too much fuss, but I wonder for how long since Access and Sql Server are fundamentally two different animals.

As mentioned, currently the program is in VS2008, but soon I hope to upgrade to VS2010 and start using Entity Framework, if that helps things.

EDIT:
Well, from the two responses below, it appears that SSCE is the standard choice. But it's not a perfect duplicate because as mentioned it lacks several features of full SS. I understand why, since such features probably aren't necessary for a small, local database. But, for an application whose data access layer was originally coded for Sql Server, seems there's at least a possibility of requiring alternative code.

Installing SSExpress on every user's machine would probably be a way to retain the SS features, but that's a step that I'm hesitant to make, given our setup.

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

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

发布评论

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

评论(2

零度℉ 2024-12-03 15:04:41

这正是他们创建“本地数据库缓存”的原因。 文件 ->新->本地数据库缓存

http://msdn.microsoft.com/en-我们/library/bb882690.aspx
http://msdn.microsoft.com/en-us/library/dd420781(v=vs.90).aspx

这称为偶尔连接的客户端。该框架将帮助您保留运行所需的数据,并允许您在重新连接时将任何数据更改与服务器同步。

This is exactly why they created "Local Database Cache". File -> New -> Local Database Cache

http://msdn.microsoft.com/en-us/library/bb882690.aspx
http://msdn.microsoft.com/en-us/library/dd420781(v=vs.90).aspx

This is called an occasionally connected client. This framework will help you keep pieces of data that you need to function and will allow you to synchronize any data changes with the server when reconnected.

穿越时光隧道 2024-12-03 15:04:41

Microsoft 的同步框架可能值得研究一下。我们正在考虑将其用于一个项目,我们需要让客户能够离线工作,然后在他们再次上线时同步到母版。

Microsoft's Sync Framework may be worth looking into. We're considering it for a project where we need to have clients able to work offline, then sync to a master when they go back online again.

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