## Microsoft Repository 2.0 自述文件

(C) 1998 Microsoft Corporation. 保留所有权利。

Repository 自述文件中补充了与 Microsoft(R) Visual Studio -- Windows 和 Internet 开发系统一起提供的和文档相关的最新信息。本文档中的信息比帮助系统中包含的信息更新。本文档中所描述的问题在后续的版本中将得到纠正。

有关 Visual Studio 6.0 套装产品的一般安装问题，包括并列产品安装，请参看安装注意事项自述文件 (install.htm)。

有关 Visual Studio 套装产品帮助系统的其他问题，请转到 MSDN(TM), Microsoft 开发者网络自述文件。

### 内容

#### Repository 概述

什么是 Microsoft Repository？

新 Microsoft Repository 2.0 中的新特征

2.0 版用户需要注意的重要信息

#### 安装

要点： 本部分包含了有关安装 Repository 2.0 的重要信息。在开始安装之前，请仔细阅读所有条目。

Repository 安装注意事项

硬盘上的 Repository 文件

#### 与 Repository 2.0 有关的问题

Repository 1.0 和 Repository 2.0 之间的差异

异步操作

属性定义中所使用的 SQL 和 API 类型

新特征

#### 限制条件和详细信息

Microsoft Repository 2.0 中已知的限制条件

详细信息

### Repository 概述

#### 什么是 Microsoft Repository？

Microsoft Repository 是一种可以实现定义和操作信息模型的技术。它被工程和软件开发工具用来共享有关设计器具的信息。所谓设计器具指的是任何想要用来共享信息而又具有复杂结构的事物 - 诸如软件组件、制造的组件、文档、地图、Web 页面等。Microsoft Repository 在一个关系型数据库中保存 repository数据。它支持两种数据库管理系统：Microsoft(R) SQL Server 6.5 版或者更高版以及 Microsoft Jet 数据库引擎 3.0 版或者更高版。

####

#### Microsoft Repository 2.0 的新特征

Microsoft Repository 2.0 在保持与 Microsoft Repository 1.0 的向后兼容性的同时对版本管理和团队开发等领域内进行了加强。

主要的新功能包括：

- 对象的版本管理：允许 repository 用户来管理 repository 对象的多个版本。
- 关系的版本管理：允许 repository 用户来管理对象之间关系的多个版本。
- 工作站管理：提供一个虚拟的 repository，在此 repository 中，用户可以对对象和关系的私有版本进行操作。签入/签出模型允许用户来控制在用户的工作站中哪些信息是可见的以及其他用户可以见到哪些改变。在此软件所附的用户文档和说明书中，对这个新的功能作了详细的描述。

#### 2.0 版用户需要注意的重要信息

用户还应该注意下面的事项：

- Microsoft Repository 2.0 在功能和接口上与 1.0 版是向后兼容的。如果所有使用 repository 数据库的应用程序都只使用 1.0 版，那么就不会发生不兼容的情况。同样的，如果所有使用 repository 数据库的应用程序都充分考虑到了版本和工作站，那么这些应用程序应该是成功的。不推荐在同一个 repository 数据库上混合使用考虑版本的应用程序和不考虑版本及工作站的应用程序。
- 因为引入了版本管理，Microsoft Repository 2.0 SQL 方案是 Microsoft Repository 1.0 方案的一个扩展。 那些不通过 repository 接口而直接访问 SQL 表的应用程序可能需要修改查询或者提供视图以保证向后的兼容性。
- 移植向导 (MigRepV2.exe) 将 Microsoft Repository 的基本数据库信息从 1.0 版转换为 2.0 版 (SQL 到 SQL， Jet 到 Jet)。在运行移植向导之前，必须已经对 Microsoft Repository 引擎 2.0 版 (V2 版) 进行注册。请注意，移植过程只能单向地从 1.0 版到 2.0 版进行。
- Microsoft Repository 2.0 不支持交易执行的 WRITETHROUGH 模式。
- Microsoft Repository 2.0 支持 Intel x86 和 Alpha 平台。

### 安装

#### Repository 安装注意事项

Microsoft Repository 的安装是在 Visual Basic 安装过程中完成的。

Microsoft Repository 要求数据访问组件已经被安装。在默认的情况下，数据访问组件的安装也是在 Visual Basic 的安装过程中完成的。然而，如果选择不安装数据访问组件而随后安装一种使用 Microsoft Repository 的第三方工具，那么在启动 Visual Basic 98 时就会遇到下列错误：

"打开 Microsoft Repository 数据库时产生一个错误。由于系统错误 126 (Microsoft Access 驱动程序 (*.MDB))，所指定的驱动程序不能被装载。Microsoft Repository Add-in for Visual Basic 正在关闭。"

要纠正这个错误，请安装数据访问组件。

#### 硬盘上的 Repository 文件

下面这些文件将被添加到 Windows SYSTEM (或者 SYSTEM32) 目录中：

- REPUTIL.DLL - Repository 引擎的实用程序

下面这些文件将被添加到 "Program Files\Common Files\Microsoft Shared\Repostry" 目录中：

- REPODBC.DLL - Repository 引擎
- REPRC.DLL - Repository 引擎的资源
- REPBROWS.EXE - 基本的 Repository 浏览器
- REPBRRC.DLL - Repository 浏览器的资源
- MIGREPV2.EXE - 移植向导用户界面
- MIGV2RC.DLL - 移植向导的资源
- MIGV2.DLL - 移植向导的算法
- REPCDLG.DLL - Repository 一般对话框
- REPCDLG.OCX - Repository 一般对话框的 ActiveX 控件
- REPCDRC.DLL - Repository 一般对话框的资源

下面这些文件将被添加到 "Program Files\Common Files\Microsoft Shared\Repostry\infoMdl" 目录中：

- REPCDE.DLL - 组件描述信息模型
- REPCOM.DLL - COM 信息模型
- REPDTM.DLL - 数据类型信息模型
- REPGEN.DLL - 一般信息模型
- UML.DLL - 统一模型化语言 (UML) 信息模型
- REPUMX.DLL - UML 扩展信息模型
- REPVCM.DLL - Visual 组件管理器模型

下面这些文件将被添加到 Visual Basic 目录中：

- REPVB.DLL - Visual Basic 的 Repository Add-in
- REPVBRC.DLL - Repository Add-in 的资源文件
- REPVBTIM.DLL - MDO 模型的类型定义

###

### 与 Repository 2.0 有关的问题

#### Repository 1.0 和 Repository 2.0 之间的差异

####

Repository 1.0 的用法

如果 repository 数据库是利用 Repository 1.0 引擎来创建的并且已经被用来只通过这个引擎来创建、操作、和检索信息模型，那么利用 Repository 2.0 引擎来运行同一个应用程序就会存在一些差异。这些差异出现在对关系的处理上，如下所列：

- 在 Repository 1.0 中，如果一个应用程序所插入的关系的名称已经存在，那么马上就会引起名称独特性冲突。而在 Repository 2.0 中，只有当已经存在的关系位于缓冲区中(例如，创建为同一个交易的一部分或者已经检索仅缓冲区中)时，才会马上引起名称独特性冲突。否则，名称独特性冲突将在提交时刻产生。

- Repository 1.0 引擎中的枚举算子，除了那些针对关系集合的， 具有静态的内容，所以在集合请求一个新的枚举算子之前，所添加的条目不会出现。而在 Repository 2.0 引擎中，枚举算子是动态的，所以添加的条目马上就会在枚举算子中出现。

- 在 Repository 1.0 中，如果 IRelationshipCol::Insert() 中的插入位置大于集合的当前合计数，这个调用就被当作 IRelationshipCol::Add() 来处理。 而在 Repository 2.0 中，如果所指定的插入位置大于当前的合计数，那么调用就降为 IRelationshipCol::Add()。对于更高的插入位置，调用将返回一个错误，因为用户大概犯了一个错误(在任何情况下这都是不好的编程)。

- 在 Repository 2.0 中，对一个未排序或者目的集合实行 IRelationshipCol::Insert() 将导致一个错误。而在 Repository 1.0 中，如果集合是排过序的，调用将在初始位置执行 IRelationshipCol::Add()。

混合模式的 Repository 1.0 和 Repository 2.0 的用法

一个 Repository 1.0 应用程序在 Repository 2.0 引擎上运行是可能实现的，其中，对同一个 repository 的版本管理操作是由其他应用程序完成的。当然，引擎必须考虑到版本管理的语义学，以及一些对非版本管理应用程序来说必须可见的语义。 如果 Repository 2.0 应用程序在一个 repository 数据库中进行版本和工作站操作，那么当 Repository 1.0 应用程序在这个数据库上运行时，就只能看到这些影响。如果在一个数据库上运行的所有的应用程序都遵循 Repository 1.0 语义学，那么就不会产生这些影响。除了上面提到的影响，还可能出现下面这些情况：

- Repository 1.0 应用程序能够使用 get_Object() 检索对象(获得已辨认版本)，删除该对象(版本被删除)，然后再一次使用 get_Object() (这次调用将辨认另外一个版本)。

- 因为在 Repository 1.0 中所有的对象没有被冻结，所以在 Repository 1.0 中更新从来不会失败。但是，在 Repository 2.0 中，所有对冻结版本或者已签出版本进行的更新操作(属性和初始集合更新)都将失败。

- 在 Repository 2.0 中，对一个已签出版本或者有后续的版本进行的删除操作将失败。而在 Repository 1.0 中则不会出现这种情况。

- 在 Repository 1.0 中， IRelationship::Delete() 完全地删除了关系，所以在起始对象和目的对象上都不再存在。而在 Repository 2.0 中，如果从目的端开始浏览，从起始版本到任何其他目的版本的关系在删除之后将继续存在。如果从起始端开始浏览，那么从该版本到所有目的版本的关系将被删除。对于 IRelationshipCol::Remove() 和 ITargetObjectCol::Remove() 来说，情况也与此相似。

- 在 Repository 1.0 中，如果一个对象是其他同种类型关系的目的，删除的传播将在此对象终止。在 Repository 2.0 种，除了要满足这个条件，删除传播将在不可改变的版本 (冻结或者已签出到另外的工作站中)终止，或者在拥有从冻结的起始版本(也就是说，没有错误)进来的关系(任何类型)的版本终止。

SQL 表

- 为了进行版本管理，Repository 2.0 SQL 表进行了广泛的修改。 如果一个 repository 数据库的所有对象都只有一个版本，那么与在此数据库上执行的 Repository 1.0 SQL 查询相对应的SQL 视图可以继续运行，没有什么改变。

- 在一个存在对象的多个版本的 repository 上执行的epository 1.0 SQL 查询可能执行完成，但是，应该根据版本管理对其语义进行检查。在某些情况下，查询可能会返回同一个对象的多个版本，而这是一个 Repository 1.0 应用程序所不能实现的。

- 在 Repository 2.0 中，表 RTblSites 中没有 NextLocalID 这一列。

- 表 RTblClassDefs 拥有一个被称为 VerPropDescs 的新列，其中是类定义在 Repository 2.0 中的保存位置。 PropDescs 列中仅仅包含 null 值而不再被使用。但是出于兼容性的考虑，仍旧保留了这一列。

杂项

下表显示了 Repository 1.0 和 Repository 2.0 之间的其他差异。

描述 | V1 引擎 | V2 引擎
IRepositoryItem::get_Item() | 超出范围的整数索引 返回 EREP_BADPARAMS。 | 超出范围的整数索引 返回 DISP_E_BADINDEX。
IRelationshipCol::Insert() ITargetObjectCol::Insert() | 如果集合是没有排序的，Insert 方法将在集合结尾插入。 | 对于未排序的集合(EREP_COL_NOT-SEQUENCED)和目的集合(EREP_RELSHIP_ORGONLY)，Insert 方法失败。
IRelationshipCol::Move() ITargetObjectCol::Move() | 对于未排序集合和目的集合，方法失败并返回 EREP_RELSHIP_ORGONLY。 | 对于未排序的集合，方法失败并返回 EREP_COL_NOT-SEQUENCED，对于目的集合，方法失败并返回 EREP_RELSHIP_ ORGONLY。
IRepositoryObjectVersion::put_Name() | 错误 EREP_OBJ_NO-NAMING-RELSHIP 没有被添加到错误队列中。 | 错误 REP_OBJ_NONAMING-RELSHIP 被添加到错误队列中。
命名唯一集合：名称为 "B" 的条目 B 被多次添加到一个命名唯一集合中 | 错误代码是 EREP_RELSHIP_DUPENAME。 | 错误代码是 EREP_RELSHIP_EXISTS。
IRepositoryItem::get_Name() | 对一个未命名的关系，操作成功 (返回 "0")。 | 失败。
IRelationshipCol::get_Item() ITargetObjectCol:: get_Item() | 参数可以是 INTID、OBJID、 Index、或者 Name。 | 参数可以是 OBJID、Index、 或者 Name。
SQL Server 上的 ExecuteQuery() | 在结果集中检查 INTID 列。 | 在隐式转换可能进行的任何时候，不仅仅接受 INTID。
刷新对象实例集合 | 刷新属性，然后刷新对象。 | 刷新对象，然后刷新属性。

#### 异步操作

响应 IRepositoryODBC::ExecuteQuery() 的对象集合装载过程可以是异步进行的。调用此方法的线程应该检查装载是否完成。 如果调用线程试图在装载进行过程中读取数据、刷新集合、或者建立一个枚举算子，那么该线程将被阻塞，直到刷新完成为止。

####

标志

- 设置/清除 "async" 选项：

RODBC_RESET_OPTIONS = 1 // 重新设置所有选项
RODBC_ASYNCH = 2 // 异步查询的执行

- 对象的装载状态：

>   READY = 1 // 装载完成
>   INPROGRESS = 2 // 装载正在进行
>   CANCELLED = 3 // 装载已经被取消(被调用者)
>   FAILED = 4 // 装载失败 (原因未知)

####

新的接口

- IObjectCol2 -- 继承自 IObjectCol.

> 附加的方法：

> - LoadStatus：获得集合的装载状态。

> > ###### 参数

> > HRESULT LoadStatus(long *piStatus) // Automation
> > HRESULT get_LoadStatus(long *piStatus) // COM

> > ###### 参数

  piStatus
  [out, retval]
  READY/INPROGRESS/CANCELLED/FAILED 之一。

> > ###### 返回值

  如果成功就返回 S_OK，如果没有提供输出参数则返回 EREP_BADPARAMS。

> - Cancel：请求取消正在进行的装载操作。

> > ###### 签名

> > HRESULT Cancel()

> > ###### 返回值

>   S_OK。

- IRepositoryODBC2 -- 继承自 IRepositoryODBC。

> 附加的方法：

> - GetOption： 获得装载选项的值。

> > ###### 签名

> > HRESULT GetOption(long iOption, VARIANT *psValue)

>   ###### 参数

>   iOption
>   [in]
>   RODBC_ASYNCH.
>   psValue
>   [out, retval]
>   VARIANT_TRUE 或者 VARIANT_FALSE，取决于是否已经设置了 RODBC_ASYNCH 选项。

>   ###### 返回值

>   如果成功就返回 S_OK，如果指定了任何其他操作则返回 EREP_BADPARAMS。

> - SetOption: 为集合的装载设置选项。当且仅当基本的数据库系统支持 async 操作时，能够设置 async 标志。

> > ###### 签名

> > HRESULT SetOption(long iOption, VARIANT sValue)

> > ###### 输入参数

> > iOption RODBC_ASYNCH 和 sValue TRUE 设置装载的 async 模式。
> > iOption RODBC_ASYNCH 和 sValue FALSE 清除 async 模式。
> > iOption RODBC_RESET_OPTIONS 重新设置装载的 async 模式。

> > ###### 返回值

> > 如果成功就返回 S_OK，如果 iOption 是 RODBC_ASYNCH 而 sValue 中指定了不是 TRUE 或者 FALSE 的值则返回 EREP_TYPE_COLMISMATCH。

其他改变

- ObjectCol 类支持 IObjectCol[default] 和 IObjectCol2。

- 如果 async 模式起作用，IObjectCol2::Refresh() 将异步地刷新对象集合 (重新装载对象集合并刷新目的对象)。 调用此方法的线程应该检查刷新是否完成。如果调用线程试图在刷新进行过程中读取数据、 刷新集合、或者建立一个枚举算子，那么该线程将被阻塞，直到刷新完成为止。

#### 属性定义中所使用的 SQL 和 API 类型

下面两个表中显示了 Repository 引擎所识别的 API 类型，还有 SQL 类型。这些值出现在 PropertyDef 对象的 APIType 属性 SQLType 属性中。有关在 SQL 和API 类型之间进行转换的信息，请参看 ODBC 程序员参考手册。

引擎识别出的 API 类型
API 类型 | 值
SQL_C_UTINYINT | -28
SQL_C_STINYINT | -26
SQL_C_ULONG | -18
SQL_C_USHORT | -17
SQL_C_SLONG | -16
SQL_C_SSHORT | -15
SQL_C_BINARY | -2
SQL_C_TINYINT | -6
SQL_C_BIT | -7
SQL_C_CHAR | 1
SQL_C_LONG | 4
SQL_C_SHORT | 5
SQL_C_FLOAT | 7
SQL_C_DOUBLE | 8
SQL_C_DATE | 9
SQL_C_TIME | 10
SQL_C_TIMESTAMP | 11

SQL 类型 | 值
SQL_LONGVARCHAR | -1
SQL_BINARY | -2
SQL_VARBINARY | -3
SQL_LONGVARBINARY | -4
SQL_BIGINT | -5
SQL_TINYINT | -6
SQL_BIT | -7
SQL_CHAR | 1
SQL_NUMERIC | 2
SQL_DECIMAL | 3
SQL_INTEGER | 4
SQL_SMALLINT | 5
SQL_FLOAT | 6
SQL_REAL | 7
SQL_DOUBLE | 8
SQL_DATETIME | 9
SQL_TIME | 10
SQL_TIMESTAMP | 11
SQL_VARCHAR | 12

#### 新特征

#### 属性

IRepository2 接口中添加了两种新的属性，以便指示数据库文件的版本。

- MajorDBVersion

> ###### 签名

> HRESULT MajorDBVersion(long *piMajorDBVersion) // Automation
> HRESULT get_MajorDBVersion( long *piMajorDBVersion) // COM

> ###### 参数

> piMajorDBVersion
> [out, retval]
> 采用这种数据格式的第一个 Repository 引擎版本的主版本号。

- MinorDBVersion

> ###### 签名

> HRESULT MinorDBVersion(long *piMinorDBVersion) // Automation
> HRESULT get_MinorDBVersion( long *piMinorDBVersion) // COM

> ###### 参数

> piMinorDBVersion
> [out, retval]
> 采用这种数据格式的第一个 Repository 引擎版本的次版本号。

#### 方法

IRepository2 接口中添加了一个新方法： CreateObjectEx()。 这个方法为指定类型的新 Repository 对象创建第一个版本。 新创建的版本被分配了一个对象-版本标识符，这个标识符被作为一个参数传递到此方法中，这一点与 IRepository::CreateObject() 不同，在 IRepository::CreateObject()中 Repository 给新创建版本分配一个 ID。其语法如下：

> ######

> 签名
> HRESULT IRepository2::CreateObjectEx(
> VARIANT TypeID,
> VARIANT ObjectID,
> VARIANT ExtVersionID,
> IRepositoryObjectVersion **ppRepObjVer);

> ######

> 参数
> TypeID
> [in]
> 其功能与 IRepository::CreateObject 相同
> ObjectID
> [in]
> 其功能与 IRepository::CreateObject 相同
> ExtVersionID
> [in]
> 这是将被分配给对象的第一个版本的对象-版本标志符 (20 字节)
> ppRepObjVer
> [out]
> 这是指向新创建版本的 IRepositoryObjectVersion 指针

### Microsoft Repository 2.0 中已知的限制条件

#### 1. 与接口及其相关方法有关的限制条件

IRepositoryObjectVersion

- MergeVersion()：关系被插入到排好序的集合的末尾。

IRelationshipCol

和 ITargetObjectCol

- Remove(): 从一个排好顺序的集合中删除元素并不会更新集合的顺序。

IVersionAdminInfo

- VersionModifyTime()： 当初始关系或者目的对象集合被修改时，并不会改变。
- ModifyByUser()： 当初始关系或者目的对象集合被修改时，并不会改变。

IRepository2

- CreateObject(): 只能从共享的 repository 中调用而不能从一个工作站中调用。 解决的办法是通过中央 repository 创建对象并将此对象包含在工作站中。

IClassDef

和 IInterfaceDef

- ObjectInstances()：不属于工作站范围。

#### 2. Repository 常数

在 Repository 文档中提到，当一个关系将一个名称赋给其目的对象的时候，这个名称的最大长度是由常数 RELSHIPNAMESIZE 所定义的 260。实际上这个值是 249。

#### 3. 名称的惯例

关系和对象的名称必须遵循下面这些惯例：

> 1. 名称的长度不得超过 249 个字符。
> 2. 名称中可以使用任何字符。
> 3. 名称的开始和结尾都可以包含空格。名称也可以是一个空的字符串。
> 4. 如果名称全部由空格组成，那它就被当作一个空字符串来处理。

这些惯例对引号中使用的名称或者保存在变量中的名称都适用。例如， 下面的 "IFolder" 接口必须满足下面这些约束条件：

> oFolder("IFolder").FolderName

-或者-

> oFolder(sIFolder).FolderName

其中： sIFolder = "IFolder"

但是，对于引号外部的名称(诸如属性名称或者关系集合名称)来说，这些指导原则并不准确。例如，下面的关系集合 "RcFolderContains" ：

> oFolder("IFolder").RcFolderContains.Count

除了字符数的限制为 127 而不是 Visual Basic 所允许的 255 之外，必须坚持 Microsoft Visual Basic 命名规则。

#### 4. 存储过程

表的存储过程名称是通过在表名称前面加上字符串 "R_i"而生成的。因为表的名称是独一无二的，这样产生的存储过程的名称也是独一无二的。但是，如果表的名称的长度大于 MaxIdentifierLength -3， 那么产生表名称的算法就会失败。鉴于这一点，用户不可以 提供一个名称长度大于 MaxIdentifierLength-3 的表。提供过长的名称会导致错误 EREP_BADNAME。

如果用户不为一个接口提供表名称，引擎将自动地 从接口名称产生表名称。如果将接口名称的打头字母"I"去掉，剩下的长度小于 MaxIdentifierLength -4，那么就将使用接口的名称作为表的名称。否则要将接口的名称截短为 MaxIdentifierLength-7，并在添加前缀 R_i 之前将 4 个字符的数字(被称为 "uniqifier")附加到名称以便使其成为独一无二的名称。

引擎使用已命名的参数来调用存储过程。一个已命名的参数的开始字符是 "@" 并且长度不得超过 MaxIdentifierLength。 因此，属性名称，同时也是列名称，的长度不得超过 MaxIdentifierLength-1。

MaxIdentifierLength 的值：

- 对于 SQL Server 6.5 为 30 个字符
- 对于 SQL Server 7.0 为 128 个字符

#### 5. 表的定义

下面这些表 没有被包含在 Repository 帮助文件中：

> - RTblSumInfo
> - RTblNamedObj
> - RTblVersionAdminInfo

下面说明了这些表的列名称和数据类型。

RTblSumInfo

RTblSumInfo 是一个与 特定接口相关的表；它的列对应于被 ISummaryInformation 接口揭示的属性。在默认的情况下， Repository 类型信息模型的类都没有执行 ISummaryInformation。 因此，在默认情况下 Repository 数据库中并不包含 RTblSumInfo 这个表。 相反， Repository 为了节省空间省略了这个表。但是，一旦向 Repository 库中插入任何执行 ISummaryInformation 的类， Repository 库就创建该表。

列名 | 数据类型 | 描述
IntID | RTIntID | 类的内部标识符。
Z_BranchID_Z | RTBrID | 指示版本图中的一个分支，其中包含了本行中属性值所适用的范围。
Z_VS_Z | RTVerID | 一个分支内版本标识符，指示了本行中属性值所适用的范围的下界。
Z_VE_Z | RTVerID | 一个分支内版本标识符，指示了本行中属性值所适用的范围的上界。
备注 | RTLongString | 备注字段。
ShortDesc | RTLongString | 对对象的描述。

RTblNamedObj

RTblNamedObj 是一个与 特定接口相关的表；它的列对应于被 INamedObject 接口揭示的属性。在默认的情况下，Repository 类型信息模型的类都没有使用 INamedObject。 因此，在默认情况下 Repository 数据库中并不包含 RTblNamedObj 这个表。 相反， Repository 为了节省空间省略了这个表。但是，一旦 向 Repository 插入任何使用了 INamedObject 的类， Repository 就创建该表。

列名 | 数据类型 | 描述
IntID | RTIntID | 类的内部标识符 class.
Z_BranchID_Z | RTBrID | 指示版本图中的一个分支，其中包含了本行中属性值所适用的范围。
Z_VS_Z | RTVerID | 一个分支内版本标识符，指示了本行中属性值所适用的范围的下界。
Z_VE_Z | RTVerID | 一个分支内版本标识符，指示了本行中属性值所适用的范围的上界。
Name | RTLongString | 对象名称。

RTblVersionAdminInfo

RTblVersionAdminInfo 是一个与 特定接口相关的表；它的列对应于被 IVersionAdminInfo 接口揭示的属性。在默认的情况下， Repository 类型信息模型的类都没有使用 IVersionAdminInfo。 因此，在默认情况下 Repository 数据库中并不包含 RTblVersionAdminInfo 这个表。 相反， Repository 为了节省空间省略了这个表。但是，一旦 向 Repository 插入任何使用了 IVersionAdminInfo 的类， Repository 就创建该表。

列名 | 数据类型 | 描述
IntID | RTIntID | 类的内部标识符。
Z_BranchID_Z | RTBrID | 指示版本图中的一个分支，其中包含了本行中属性值所适用的范围。
Z_VS_Z | RTVerID | 一个分支内版本标识符，指示了本行中属性值所适用的范围的下界。
Z_VE_Z | RTVerID | 一个分支内版本标识符，指示了本行中属性值所适用的范围的上界。
VersionCreateTime | Date/Time | 该版本被创建的时间。
VersionModifyTime | Date/Time | 版本被修改的时间。
CreateByUser | RTLongString | 创建该版本的用户。
ModifyByUser | RTLongString | 修改该版本的用户。

#### 6. 其他限制条件

- 移植向导 (MigRepV2.exe)、Repository 浏览器 (Repbrows.exe)、以及 Visual 组件管理器 (VCM) 不支持文件的 DSN (数据源名称)。这些工具只能支持 Access 或者 SQL Server 类型的 DSN。

- 在移植向导中，如果对 SQL Server 类型的 DSN 使用移植向导，系统将要求 输入一个用户名称和相应的密码，除非已经使用 Windows NT 验证选项(在 ODBC 数据源管理器中) 对该 DSN 进行了配置。

- 在 "合并版本示例" 主题中，第二段有一处不准确的地方。 在合并之后，版本 V8 的属性应该从(Large, Red, null) 变为 (Medium, Red, null)。

- CollectionDefFlags 枚举的文档中没有提到如下的标志：

  COLLECTION_NEWORGVERSIONSDONOTPARTICIPATE = 64

  这个标志与同一个枚举中的另外一个标志是相关的：

  COLLECTION_NEWORGVERSIONSPARTICIPATE = 32

> 这两个标志的含义正好相反。因此，就不能在同一时刻设置这两个标志。 但是，因为这两个标志的默认设置都是清除，在同一时刻两个标志都可以是清除。 如果两个标志都是清除， Repository 就按照 COLLECTION_NEWORGVERSIONSPARTICIPATE 标志被设置的方式操作。 也就是说，在创建 repository 对象的一个新版本的时候， Microsoft Repository 确实将新的初始集合 从一个原先创建版本拷贝到一个后续版本中。

- 如果 SQLSize 被设置为大于 65535 的值，引擎就会将输入值除以 65536 并将 SQLSize 设置为所得到的余数，而不会返回错误。

- 在 "移植算法"主题中引用了两个表， RTblRelColPairs 和 RTblTimestamp。在 Repository 2.0 数据库中， 第一个表并不存在，而第二个表已经被 RTblVersionAdminInfo 取代。

#### 详细信息

您可以从下面这些途径获得有关 Microsoft Repository 的详细信息：

- 在 Microsoft Repository Web 站点上查找最新消息 (http://www.microsoft.com/repository)。 您也可以从这个站点下载 Repository 文档。
- 在 Microsoft Visual Studio 6.0 文档中，您将发现 Repository 程序员指南、Repository 参考手册、Repository 浏览器、以及转换 Repository 1.0 数据库。要定位这些文档，请从要定位这些文档，请从顶部开始并沿着下面的路径查找：

  > > MSDN 库 Visual Studio 6.0
  > > Visual Studio 文档
  > > 组件、设计和分析工具
  > > Microsoft Repository 2.0 文档

- 在 Microsoft Visual Basic 6.0 文档中，您将发现 Repository 程序员的 Visual Basic 指南和 Microsoft Repository Visual Basic Add-in 参考手册。要定位这些文档，请从顶部开始并沿着下面的路径查找：

  > > MSDN 库 Visual Studio 6.0
  > > Visual Basic 文档
  > > 与 Visual Basic 一起使用 Repository