access数据库移动目录,前端数据库access找不到指定的数据库,怎么修改

因为APP 01服务器作为SharePoint管理中心网站的宿主服务器必须作为SharePoint Farm里第一台服务器进行安装。然后再安装部署其他三台SharePoint服务器

l Server Farm:适用于多台服务器以服务器场的方式安装。

Location”切换箌安装路径界面进行修改最后点击“Install Now”按钮开始安装。

13.     在该数据库配置界面中依次在以下四个文本框中输入环境配置信息:

l Username:连接SharePoint配置库的帐号。帐号的详细配置参见第3章的准备工作里帐号部分描述该帐号也将作为SharePoint 2010 Timer服务的服务帐号。

输入完成后点击“Next”按钮进入到配置服务器场安全密钥界面。当其他服务器想加入该SharePoint场时需要输入该密钥才能顺利加入SharePoint场。

14.     输入安全密钥和再次输入确认后点击“Next”按钮进入下一步。由于该服务器是SharePoint Farm里的第一台服务器默认情况下,也将是SharePoint管理中心网站的宿主服务器

15.     在配置SharePoint管理中心网站的界面中,鈳以采用系统随机分配的网站端口也可以自行指定管理中心网站的端口号(注意避开常用端口号)。同时指定管理中心网站的认证方式点击“Next”进入配置确认界面。

l 完成对SharePoint 2010 Timer服务的初始化设置其运行服务帐号为指定的帐号,并启动该服务

业务数据连接服务,简称BDC或BCS服務它为我们提供了一整套的将SharePoint 2010与外部数据相连的功能。

文档转换服务它为我们提供了Word、HTML等文档格式互相转换的功能支持。

Excel Services相当于是SharePoint提供的一个在线的简单Excel呈现功能利用Excel Services,用户可以方便快速的在Web上发布Excel从而让更多群体直接通过浏览器访问浏览。

托管元数据是一个集中管理的术语的分层集合用户可以定义这些术语,然后将其用作SharePoint 2010 中项目的属性托管元数据服务提供了一个集中式的元数据的管理维护。

PerformancePoint Service昰一种绩效管理服务可用来监视和分析业务。PerformancePoint Service通过提供灵活易用的仪表板、记分卡、报表和关键绩效指标 (KPI) 构建工具用来帮助组织内的烸个人做出符合整个公司目标和策略的明智业务决策。

搜索服务提供了一个用于企业级搜索的解决方案。用户可以全文检索企业内部各類内容源里的数据以更高效方式查找到信息。

用户配置资料服务是SharePoint 2010 中的共享服务它提供一个集中位置来配置和管理以下个性化设置:

l  組织浏览和管理设置

部件。使用这些功能管理员可以了解用户正在执行的操作并更好地了解他们需要从网站中获取的信息。

State Service状态服务应鼡程序是一个比较特别的服务应用程序它无法通过SharePoint管理中心里的服务应用程序直接创建,只能通过SharePoint管理中心的配置向导或者通过PowerShell命令行方式进行创建由于配置向导不具可管理性,这里只说明如何通过PowerShell命令行方式创建

同时需要理解状态服务应用程序是一项基础服务,本身没有管理配置界面但为其他的服务应用程序及SharePoint应用提供了基础服务支撑。

此时会创建名称为“My State Service Proxy”的服务代理并自动与“My State Service”该状态服務应用程序关联在默认的代理组里。效果如下:

点击“OK”按钮开始创建:

点击“OK”按钮开始创建Web分析服务应用程序

点击“OK”按钮开始创建,创建成功后在管理服务应用程序中就可以看到该服务

点击“Next”按钮进入配置数据库界面。

在确认输入值后点击“OK”按钮开始创建。

确定输入值后点击“OK”按钮开始创建Excel服务应用程序。

5.        稍等一会后将提示成功创建Excel服务应用程序的信息。同时返回管理服务应用程序頁面后刷新后可以看到新建出来的Excel服务应用程序,并该服务已处于Started启动状态

确定输入值后,点击“Create”按钮开始创建PerformancePoint服务应用程序

l Name:託管元数据服务应用程序的名称。

在确定输入值后点击“OK”按钮开始创建托管元数据服务应用程序。

在确定输入值后点击“OK”开始创建Visio服务应用程序。

l Application Pool:推荐新建应用程序池注意:此处应用程序池用的服务帐号,请确保它在本地管理员组里

l Profile Database:用户资料的数据库信息,包括数据库实例名数据库名称和数据库验证方式。

l Synchronization Database:保存同步信息的数据库包括数据库实例名,数据库名称和数据库验证方式

l Social Tagging Database:社会标签的数据库信息,包括数据库实例名数据库名和数据库验证方式。

完成上述信息后点击“Create”按钮开始创建用户群体配置资料服務应用程序。

服务器的角色是由服务器上运行的服务来决定的也就是说,决定SharePoint Farm中的一台服务器是WFE、APP或DB是由该台服务器承载的服务决定嘚。对于DB角色服务器来说比较容易理解,SQL Server所在服务器即为DB服务器而对于WFE和APP,则可以这么理解:

APP服务器:凡是在服务器上启动了5.4章节里提及的一个或多个服务应用程序中的对应的服务后该服务器都可以成为APP服务器(一般称之为某某服务应用服务器,或综合的应用服务器)比如,启用了Excel Services的SharePoint服务器就可以称之为Excel Services应用服务器

6.        由于在实际应用中,WFE服务器都是专门用于作为Web前端服务器存在因此可以停止关闭除了以下服务外地所有其他服务,以保证WFE服务器的专用性

接下来,根据实际需要分别在APP01和APP02服务器上启用相应的其他的服务,以承载其莋为应用服务器的角色注意,有些应用服务可以直接在管理服务界面上启动有些服务(比如搜索服务)则需要进去服务应用程序的配置管理界面中进行配置更新才可以顺利应用。这部分内容超出了本手册范围这里不再进行描述,请参考SharePoint相关资料进行配置管理

注:由於SharePoint管理中心网站的特殊性,我们一般将它放在某台应用服务器上(如APP01)供内部管理员使用SharePoint管理中心网站是在运行SharePoint配置向导就已经自动创建出来。可以在服务中找到一项名为“Central Administration”的服务即为SharePoint管理中心网站的服务启动了该服务表示该服务器同时也是SharePoint管理中心网站的宿主服务器。

打开SharePoint管理中心网站进入“Application Management”里的“Manage Web Applications”,在该管理界面中进行门户网站的创建和管理等各类操作这部分内容超出了手册范围,这里將不再进行描述详细可以参考SharePoint 2010相关资料。

注:根据SharePoint应用的实际情况描述其部署包情况及部署步骤等

}
  • 现在,公司用的数据库应用软件,前端用的是V FOXPRO 进行开发的.后端是SQL2000数据库.我想问用OFFICE 里带的ACCESS取代VFOXPRO,可以吗? 是否要还需要VB或VC等其它软件配合才行. 或者说有些代码必须要VB或VC来写.才能构成┅个完整的数据库应用软件.

  • 可以啊access很牛的

    如果你的这个程序基本不涉及网络(共享除外)以及第三方程序的话,access绝对胜任了access也支持vb,基本的操作也足够了

    其实office里的都很牛,只是很少有人用而已见过一个公司用excel开发erp的……

  • Server数据库,而且Access本身优化了对SQL Server的访问性能是VB也鈈能比拟的。

    至于Access做出来的界面完全可以做到非常漂亮,您可以参考Access MVP黄海的大作连接地址:

    另外,个人觉得+SQL Server客户端只用浏览器就可鉯,可以使用.NET的智能客户端技术便于软件的分发、维护及升级。至于开发语言则考虑C#或VB什么的都行

  • 看来 access2007是个合格的前端界面程序了

  • 学習了一下上面引用的网址上的说明,个人感觉这基本上是一种自找麻烦的作法

  • ACCESS  的传递查询处理数据库服务器上的 SQL。与平时所见的数据库應用(如前几位说的ASP+SQL+VC等)的查询有什么不同我大体知道是查询都是在SQL上完成的。客户端只是接收一个结果我也是想要这个结果(例如遠程终端的例子,虽说是在服务器中进行的但也是想查询在专门的数据库服务器中进行,而不是ACCE客户端所在的本机或服务器查询) ACCESS的查询速度和结果在客户端能接受吗?

  • Server数据库而且Access本身优化了对SQL Server的访问,性能是VB也不能比拟的

    至于Access做出来的界面,完全可以做到非常漂煷您可以参考Access MVP黄海的大作,连接地址:

    另外个人觉得ASP.Net+SQL的方式并不是适合所有人或项目,在企业内部用Access ADP +SQL Server才是最方便快捷,开发周期最短实现成本最低的应用模式。

  • 我看了下微软网站上的数据开发的一些文章觉得小企业还是对真正的企业应用模式的理解还是有差距,洳公司采用的这个数据库应用模式只能说是初步的企业应用(用在企业中就算是吧)。一但企业规模扩大或业务模式变化这个软件就荇不通了。

          我看了此文: 这是个好的开发标准化思路。各种软件开发方式也许用上了这个思路但开发人员在介绍时,是没有讲到这些嘚好象也没有用上。

          所以我觉得:ACCESS代替VFP不是最重要的,是这个软件开发模式和方向要正确感谢微软提供的文章。

}

容量规划要求以建议的 Office Communications Server 2007 R2 用户模型為基础本节介绍这些用户模型,并提供有助于您为组织进行容量规划的信息

本节后面所述的容量规划要求与建议都是以本节Φ的用户模型为基础。

90% 的用户从内部连接

10% 的用户通过边缘服务器和控制器(推荐)进行连接

平均 80 个联系人使用移动设備

平均 50 个联系人使用所有其他设备

70% 的联系人在组织内

10% 的企业用户是远程用户

10% 的联系人是联盟联系人

10% 的联系人是公共 IM 联系人

每个用户每小时 2 個 IM 会话

每个会话 10 条即时消息

平均消息大小为 400 字节

平均每个多方 IM 会话有三人参加

下表介绍的会议模型将用作本节后面所述的容量规划要求与建议的基础

计划的会议与“立即开会”会议

每种类别各占 50%。

5% 的用户将在工作时间参加会议

15%:PSTN 音频(通过第三方音频会议提供商)、PowerPoint。

10%:PSTN 音频(通过第三方音频会议提供商)、应用程序共享

15%:组 IM(利用通讯组集成)。

10%:仅 PSTN 音频电话拨入式会议

25%:VoIP 音频、PSTN 电话撥入式会议和视频、应用程序共享。

5%:VoIP 音频、PSTN 电话拨入式会议、IM 和应用程序共享

10%:VoIP 音频、PSTN 电话拨入式会议、视频、IM。

在将会议助理与 VoIP 音頻和 PSTN 电话拨入式会议音频组合使用的会议中VoIP 用户与电话拨入式会议用户之比为 2:1。

对于应用程序共享存在两种类型的应用程序共享:使鼡 Web 会议服务器、基于持续性共享对象模型 (PSOM) 的应用程序共享,以及以新的应用程序共享服务器为基础、基于远程桌面协议 (RDP) 的应用程序共享此用户模型假定所有临时会议当中有 80% 的会议使用基于 RDP 的应用程序共享,有 20% 使用基于 PSOM 的应用程序共享对于计划的会议,此用户模型假定采鼡 PSOM 和 RDP 的应用程序共享各占一半

假定:只有一位参与者的会议不使用 RDP 应用程序共享。如果是有两位参与者的计划的会议此模型假定 RDP 应用程序共享占 20%。如果是临时会议此模型假定 RDP 应用程序共享占 10%。

下表介绍的会议内容大小将用作本节后面所述的容量规划要求与建议的基础

表 3. 会议内容大小模型

5,000 外加 120 名进行桌面共享的用户

联系人列表中的内部用户的百分比

每个用户的平均联系囚数

每个用户的最大联系人数

每个用户的最小联系人数

每个用户每天登录的小时数

每个用户每天更新状态的次数

每个用户每天的即时消息對话数

每个用户每天的即时消息会议数

每个用户每次会议(对等)发送的即时消息数

每小时的即时消息会话数

多方会话的平均参与人数

指萣时间点的并发会议用户数

每个用户每天的状态询问次数

每个用户每天的联系人更改次数

并发桌面共享用户的百分比

桌面共享会议的最大鼡户数

桌面共享会议的持续时间

下表列出了有关桌面共享模型的信息。

表 5. 桌面共享模型

上表中的使用模型基于对 Proliant 的测试

下表介绍建议的响应组服务用户模型用作本节后面所述的容量规划要求与建议的基础。

  • 使用默认保持音乐文件

表 6. 响应组服务用户模型

活动代理数(正式和非正式)

每个智能寻线使用一个唯一队列,一级互动响应组使用两个

每个智能寻线使用一个唯一队列一级互动响应组使用两个

在互动语音响应 (IVR) 中使用语音识别的工作流与在 IVR 中仅使用双音多频 (DTMF) 的工作流所占百分比對比

智能寻线数(简单智能寻线与复杂智能寻线混用,各占 50%)

每个代理所属的平均组数

每个队列的组数(平均值)

90%:一个组 10%:两个组

90%:一個组 10%:两个组

同时进行的响应组呼叫数

平均呼叫持续时间(IVR 部分 + 保持音乐)

使用代理时的平均呼叫持续时间

正式代理在一天内(按每天 8 小時)的登录/注销循环次数

下表提供了有助于为组织进行容量规划的信息

表 7. 每个拓扑支歭的最多用户数

Communicator)。后端数据库必须运行在一台四路处理器、四核或八路处理器、双核的 2.0 GHz+ 计算机上

必须为此更大的服务器和用户支持部署 QFE 1。

边缘服务器拓扑假定全部用户群的 10% 是从 Intranet 之外连接的下表显示了以下每个边缘服务器角色和拓扑所支持的最大客户端连接数。

表 8. 边缘服务器拓扑支持的最多客户端数

访问边缘服务:5,000 个客户端连接

Web 会议边缘服务:1,000 个客户端连接

建议部署 Director 用于外部访问

120 个并发桌面共享用户

表 10. 存储磁盘容量规划

企业版池后端数据驱动器

企业版池 RTC 日志

监控(QoE 和 CDR)數据日志驱动器

表 11. 存档和监控数据库存储容量规划

按每秒 320 条消息,每条消息 400 字节

假定客户端不创建视频呼叫的 QoE 数据

表 12. 群聊容量规划

每个用户参与 30 个聊天室

每个聊天室有 30 个参与者

每台服务器每秒启动两个用户连接

每秒 40 条消息(所有聊天室)

聊天室可以支持 30 个以上的参与者群聊客户端能够支持 30 个以上的聊天室。但聊天室中如果参与者过多可能会影响服务器性能聊天室经过测试的配置为最多 1,000 个参与者。有大量参与者的聊天室的使用应限制为不超过所有创建的聊天室的 10%

表 13. 持续性共享对象模型 (PSOM) 应用程序的应用程序共享容量规划

15 个会议,90 个用户

每个共享者发送:713.57

每个查看者接收:552.92

表 14. 中介服务器容量规划

90% 内部用户10% 外部/远程用户

在上表中,假定 CPU 使用率占容量的 75%
中介服务器的扩展数量取决於用户的位置,主要是用户距离中介服务器有多远对于内部网络之外的用户,媒体堆栈使用较低的比特率这将显著影响性能。

对通讯簿服务器的容量规划要求您规划通讯簿服务器数据库和通讯簿 Web 查询服务数据库的大小、下载文件的大小以及将访问通讯簿 Web 查询服务的 Office Communicator Mobile(适鼡于 Windows)客户端的数量

用于通讯簿服务器数据库和通讯簿服务器创建下载文件所在的文件服务器的磁盘大小主要取决于必须存储的联系人嘚数量。(该文件服务器还可用于存储其他数据有关详细信息,请参阅中的“文件夹”一节一种用于估计通讯簿服务器将在数据库和丅载文件中存储的联系人数量的方法是,假定每个用户有两个联系对象因此,可以通过将组织中用户的数量乘以二来估计通讯簿服务器嘚存储要求

  • 通讯簿下载文件大小的一般性假设:
    • 100,000 个联系人,2.5 GB 存储用于下载文件(按每名员工两个联系人)
  • 通讯簿 Web 查询数据库大小的一般性假设:
  • 1 GB用于数据库日志

表 15. 企业版池的通讯簿 Web 查询服务性能

18,000(启用了语音的用户的 60%)

为 30% 的用户启用了統一通信。

每秒 100 次查询对性能的影响很小

表 16. 音频/视频容量规划

  • 上面提供的媒体流的宽带数值除了实际的已编码媒体外,还包含组帧、加密和 IP 路由信息的所有开销
  • 平均编解码器带宽值是以测量值为基础,根据通常的活动级别值从最大理论带宽推算出来嘚音频活动级别考虑到了流中的帐户语音活动。视频活动级别考虑到了视频图象中的动作量
  • RT 窄带音频的活动级别略高一些,以允许在 PSTN 網关中对 Office Communications Server VoIP 到 PSTN 的呼叫进行低于最佳的语音活动检测如果所部署的 PSTN 网关未启用语音活动检测,则应将此数值再提高 15%
  • 全景视频的活动级别低於常规视频流的活动级别,原因是全景图像中背景区域的相对比例要高一些

对于基本媒体网关,网关和中介服务器之间每个并发呼叫所要求的带宽为 80 Kbps将这个数字乘以每个网关的端口数可以精确估计出中介服务器网关一侧所需的带宽。在 Office Communications Server 一侧对带寬的要求相当低。

配置中介服务器时应接受默认的媒体端口网关范围 (60,000 - 64,000)。缩小端口范围会大大降低服务器容量缩小端口范围只应在特殊原因下执行,并且应由熟知媒体端口要求和方案的管理员来执行因此,建议不要更改默认端口范围

高带宽流量(如语音和视频)往往會对没有适当设置的网络带来压力。将媒体流量限制在已知的端口范围可以更方便地解决此类问题

8 小时工作日的移动訪问需要大约 1 MB 带宽。这是基于以下使用:

  • 一个通讯组(15 个用户)
  • 联系人列表中的 80 个成员(每个用户每小时更新四次状态)
  • 一个一小时更新㈣次状态的已标记联系人
  • 每天 12 次电话呼叫其中每小时 1 次电话呼叫(每两个小时 1 次传入呼叫和 1 次传出呼叫)
  • 每两个小时一次 IM 会话
}

我要回帖

更多关于 access找不到指定的数据库 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信