(C) 1998 Microsoft Corporation. 保留所有权利。
Repository 自述文件中补充了与 Microsoft(R) Visual Studio -- Windows 和 Internet 开发系统一起提供的和文档相关的最新信息。本文档中的信息比帮助系统中包含的信息更新。本文档中所描述的问题在后续的版本中将得到纠正。
有关 Visual Studio 6.0 套装产品的一般安装问题,包括并列产品安装,请参看安装注意事项自述文件 (install.htm)。
有关 Visual Studio 套装产品帮助系统的其他问题,请转到 MSDN(TM), Microsoft 开发者网络自述文件。
Microsoft Repository 是一种可以实现定义和操作信息模型的技术。它被工程和软件开发工具用来共享有关设计器具的信息。所谓设计器具指的是任何想要用来共享信息而又具有复杂结构的事物 - 诸如软件组件、制造的组件、文档、地图、Web 页面等。Microsoft Repository 在一个关系型数据库中保存 repository数据。它支持两种数据库管理系统:Microsoft(R) SQL Server 6.5 版或者更高版以及 Microsoft Jet 数据库引擎 3.0 版或者更高版。
Microsoft Repository 2.0 在保持与 Microsoft Repository 1.0 的向后兼容性的同时对版本管理和团队开发等领域内进行了加强。
主要的新功能包括:
用户还应该注意下面的事项:
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 正在关闭。"
要纠正这个错误,请安装数据访问组件。
下面这些文件将被添加到 Windows SYSTEM (或者 SYSTEM32) 目录中:
下面这些文件将被添加到 "Program Files\Common Files\Microsoft Shared\Repostry" 目录中:
下面这些文件将被添加到 "Program Files\Common Files\Microsoft Shared\Repostry\infoMdl" 目录中:
下面这些文件将被添加到 Visual Basic 目录中:
如果 repository 数据库是利用 Repository 1.0 引擎来创建的并且已经被用来只通过这个引擎来创建、操作、和检索信息模型,那么利用 Repository 2.0 引擎来运行同一个应用程序就会存在一些差异。这些差异出现在对关系的处理上,如下所列:
混合模式的 Repository 1.0 和 Repository 2.0 的用法
一个 Repository 1.0 应用程序在 Repository 2.0 引擎上运行是可能实现的,其中,对同一个 repository 的版本管理操作是由其他应用程序完成的。当然,引擎必须考虑到版本管理的语义学,以及一些对非版本管理应用程序来说必须可见的语义。 如果 Repository 2.0 应用程序在一个 repository 数据库中进行版本和工作站操作,那么当 Repository 1.0 应用程序在这个数据库上运行时,就只能看到这些影响。如果在一个数据库上运行的所有的应用程序都遵循 Repository 1.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() 的对象集合装载过程可以是异步进行的。调用此方法的线程应该检查装载是否完成。 如果调用线程试图在装载进行过程中读取数据、刷新集合、或者建立一个枚举算子,那么该线程将被阻塞,直到刷新完成为止。
标志新的接口
- READY = 1 // 装载完成
- INPROGRESS = 2 // 装载正在进行
- CANCELLED = 3 // 装载已经被取消(被调用者)
- FAILED = 4 // 装载失败 (原因未知)
附加的方法:
- LoadStatus:获得集合的装载状态。
参数
- HRESULT LoadStatus(long *piStatus) // Automation
- HRESULT get_LoadStatus(long *piStatus) // COM
参数
返回值
- Cancel:请求取消正在进行的装载操作。
签名
HRESULT Cancel()
返回值
- S_OK。
附加的方法:
- 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。
其他改变
下面两个表中显示了 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 接口中添加了两种新的属性,以便指示数据库文件的版本。
签名
- HRESULT MajorDBVersion(long *piMajorDBVersion) // Automation
- HRESULT get_MajorDBVersion( long *piMajorDBVersion) // COM
参数
- piMajorDBVersion
- [out, retval]
- 采用这种数据格式的第一个 Repository 引擎版本的主版本号。
签名
- 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 指针
IRepositoryObjectVersion
IRelationshipCol 和 ITargetObjectCol
IVersionAdminInfo
IRepository2
IClassDef 和 IInterfaceDef
在 Repository 文档中提到,当一个关系将一个名称赋给其目的对象的时候,这个名称的最大长度是由常数 RELSHIPNAMESIZE 所定义的 260。实际上这个值是 249。
关系和对象的名称必须遵循下面这些惯例:
- 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 命名规则。
表的存储过程名称是通过在表名称前面加上字符串 "R_i"而生成的。因为表的名称是独一无二的,这样产生的存储过程的名称也是独一无二的。但是,如果表的名称的长度大于 MaxIdentifierLength -3, 那么产生表名称的算法就会失败。鉴于这一点,用户不可以 提供一个名称长度大于 MaxIdentifierLength-3 的表。提供过长的名称会导致错误 EREP_BADNAME。
如果用户不为一个接口提供表名称,引擎将自动地 从接口名称产生表名称。如果将接口名称的打头字母"I"去掉,剩下的长度小于 MaxIdentifierLength -4,那么就将使用接口的名称作为表的名称。否则要将接口的名称截短为 MaxIdentifierLength-7,并在添加前缀 R_i 之前将 4 个字符的数字(被称为 "uniqifier")附加到名称以便使其成为独一无二的名称。
引擎使用已命名的参数来调用存储过程。一个已命名的参数的开始字符是 "@" 并且长度不得超过 MaxIdentifierLength。 因此,属性名称,同时也是列名称,的长度不得超过 MaxIdentifierLength-1。
MaxIdentifierLength 的值:
下面这些表 没有被包含在 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 | 修改该版本的用户。 |
COLLECTION_NEWORGVERSIONSDONOTPARTICIPATE = 64
这个标志与同一个枚举中的另外一个标志是相关的:
COLLECTION_NEWORGVERSIONSPARTICIPATE = 32
这两个标志的含义正好相反。因此,就不能在同一时刻设置这两个标志。 但是,因为这两个标志的默认设置都是清除,在同一时刻两个标志都可以是清除。 如果两个标志都是清除, Repository 就按照 COLLECTION_NEWORGVERSIONSPARTICIPATE 标志被设置的方式操作。 也就是说,在创建 repository 对象的一个新版本的时候, Microsoft Repository 确实将新的初始集合 从一个原先创建版本拷贝到一个后续版本中。
您可以从下面这些途径获得有关 Microsoft Repository 的详细信息:
MSDN 库 Visual Studio 6.0
Visual Studio 文档
组件、设计和分析工具
Microsoft Repository 2.0 文档
MSDN 库 Visual Studio 6.0
Visual Basic 文档
与 Visual Basic 一起使用 Repository