# Microsoft Repository Readme

## Microsoft Repository 2.0 Readme

© 1998 Microsoft Corporation. All rights reserved.

Repository Readme includes updated information for the documentation provided with Microsoft® Visual Studio -- Development System for Windows and the Internet. The information in this document is more up-to-date than the information in the Help system. Many of the issues outlined in this document will be corrected in upcoming releases.

For general installation issues on the Visual Studio 6.0 suite of products, including side by side product installation, see the Installation Notes readme (install.htm).

For other issues on the Help system of the Visual Studio suite of products, go to MSDN™, the Microsoft Developer Network Readme.

### Contents

##### Repository Overview

What is Microsoft Repository?

NEW What is New in Microsoft Repository 2.0

Important Information for Release 2.0 Customers

##### Installation

Important: This section contains vital information about installing Repository 2.0. Please read all items carefully before you begin your installation.

Repository Installation Notes

Repository Files on Your Hard Disk

##### Repository 2.0 Issues

Differences between Repository 1.0 and Repository 2.0

Asynchronous Operation

SQL and API Types Used in Property Definitions

New Features

##### Limitations and More Information

Known Limitations in Microsoft Repository 2.0

For More Information

### Repository Overview

#### What Is Microsoft Repository?

Microsoft Repository is an enabling technology for defining and populating information models. It is used by engineering and software development tools to share information about engineered artifacts. Engineered artifacts are things like software components, manufactured components, documents, maps, Web pages - anything about which you might want to share information that has complex structure. Microsoft Repository stores repository data in a relational database. Two database management systems are supported: Microsoft® SQL Server version 6.5 or later and the Microsoft Jet database engine version 3.0 or later.

####

#### What Is New in Microsoft Repository 2.0?

Microsoft Repository 2.0 contains significant enhancements in the areas of version management and team development while maintaining backward compatibility with Microsoft Repository 1.0 interfaces.

The major areas of new functionality are:

- Versioning of objects: allows the repository user to maintain multiple versions of repository objects.
- Versioning of relationships: allows the repository user to maintain multiple versions of relationships between objects.
- Workspace management: provides a virtual repository for users in which they can manipulate private versions of objects and relationships. A Checkin/Checkout model allows users to control what information is visible in the users' workspaces and what changes are made visible to other users. This new functionality is described in detail in the user documentation and specifications that accompany the software.

#### Important Information for Release 2.0 Customers

Users should also be aware of the following:

- Microsoft Repository 2.0 is backward-compatible with version 1.0 functionality and interfaces. If all of the applications using a repository database use only version 1.0 functionality, no incompatibilities will occur. Likewise, if all the applications using a repository database are version- and workspace-aware, they should be successful. Mixing applications that are version-aware with applications that are not version- and workspace-aware on the same repository database is not recommended.
- The Microsoft Repository 2.0 SQL schema is an extension of the Microsoft Repository 1.0 schema because of the introduction of versioning. Applications that bypass repository interfaces to access SQL tables directly may have to modify queries or provide views for backward compatibility.
- The migration wizard (MigRepV2.exe) converts Microsoft Repository underlying database information from version 1.0 to version 2.0 (SQL to SQL, and Jet to Jet). You must have the Microsoft Repository engine version 2.0 (V2 engine) registered before running the migration wizard. Notice that the migration is one way only, from version 1.0 to version 2.0.
- Microsoft Repository 2.0 provides no support for the WRITETHROUGH mode of transaction execution.
- Microsoft Repository 2.0 supports Intel x86 and Alpha platforms.

### Installation

#### Repository Installation Notes

Microsoft Repository is installed during a Visual Basic installation.

Microsoft Repository requires that the Data Access component be installed. By default, the Data Access component is installed during a Visual Basic installation. However, if you choose not to install the Data Access component, and then install a third party tool that uses Microsoft Repository, you will encounter the following error when starting Visual Basic 98:

"An error occurred while opening the Microsoft Repository database. Specified driver could not be loaded due to system error 126 (Microsoft Access Driver (*.MDB)). Microsoft Repository Add-in for Visual Basic is shutting down."

To correct this problem, install the Data Access component.

#### Repository Files on Your Hard Disk

The following files will be added to the Windows SYSTEM (or SYSTEM32) directory:

- REPUTIL.DLL - Utilities for the Repository engine

The following files will be added to the "Program Files\Common Files\Microsoft Shared\Repostry" directory:

- REPODBC.DLL - The Repository Engine
- REPRC.DLL - Resources for the Repository Engine
- REPBROWS.EXE - A basic Repository Browser
- REPBRRC.DLL - Resources for the Repository Browser
- MIGREPV2.EXE - The Migration Wizard User Interface
- MIGV2RC.DLL - Resources for the Migration Wizard
- MIGV2.DLL - The Migration Wizard Algorithm
- REPCDLG.DLL - The Repository Common Dialog
- REPCDLG.OCX - ActiveX controls for the Repository Common Dialog
- REPCDRC.DLL - Resources for the Repository Common Dialog

The following files will be added to the "Program Files\Common Files\Microsoft Shared\Repostry\infoMdl" directory:

- REPCDE.DLL - The Component Description Information Model
- REPCOM.DLL - The COM Information Model
- REPDTM.DLL - The Data Type Information Model
- REPGEN.DLL - The Generic Information Model
- UML.DLL - The Unified Modeling Language (UML) Information Model
- REPUMX.DLL - The UML Extension Information Model
- REPVCM.DLL - The Visual Component Manager Model

The following files will be added to the Visual Basic directory:

- REPVB.DLL - The Repository Add-in for Visual Basic
- REPVBRC.DLL - Resource file for Repository Add-in
- REPVBTIM.DLL - Type definitions for the MDO Model

###

### Repository 2.0 Issues

#### Differences Between Repository 1.0 and Repository 2.0

#####

Repository 1.0 Usage

If the repository database was created using the Repository 1.0 engine and has been used for information model creation, population, and retrieval only through this engine, there will be some differences when you run the same application with the Repository 2.0 engine. The differences arise from the treatment of relationships, as listed below:

- In Repository 1.0, if an application inserts a name-unique relationship with an existing name, the name-uniqueness violation is caught immediately. In Repository 2.0, the violation is caught immediately only if the existing relationship is in the cache (for example, created as part of the same transaction or retrieved into the cache already). Otherwise, the name-uniqueness validation occurs at commit time.

- Enumerators in the Repository 1.0 engine, except those for relationship collections, have static contents, so added items do not appear until a new enumerator is requested from the collection. In the Repository 2.0 engine, enumerators are dynamic, so added items appear immediately in the enumerator.

- In Repository 1.0, if the insertion position in IRelationshipCol::Insert() is larger than the current count of the collection, the call is treated as IRelationshipCol::Add(). In Repository 2.0, if the specified insertion position is one greater than the current count, then the call reduces to IRelationshipCol::Add(). For higher insertion positions, the call returns an error since the user presumably made a mistake (it would be bad programming in any case).

- Invoking IRelationshipCol::Insert() on a nonsequenced or destination collection results in an error in Repository 2.0. In Repository 1.0, the call performs IRelationshipCol::Add() on the origin if the collection is sequenced.

Mixed-mode Repository 1.0 and Repository 2.0 Usage

It is conceivable that a Repository 1.0 application might be run on the Repository 2.0 engine, in which versioning operations are performed by other applications on the same repository. The engine of course has to respect the semantics of versioning, and some of those semantics will necessarily be visible to the nonversioning application. A Repository 1.0 application can only see these effects when operating on a repository database in which Repository 2.0 applications are performing version and workspace operations. These effects do not arise when all applications on a repository database are following Repository 1.0 semantics. In addition to the effects mentioned above, the following could arise:

- A Repository 1.0 application can retrieve an object using get_Object() (it gets the resolved version), delete it (the version is deleted), and still use get_Object() a second time (the call resolves to a different version).

- Since all objects are unfrozen in Repository 1.0, updates never failed in Repository 1.0. However, in Repository 2.0, all update operations (property and origin collection updates) on a frozen version or a checked-out version will fail.

- In Repository 2.0, a delete operation on a checked-out version or a version with a successor will fail. Neither of these situations could arise in Repository 1.0.

- In Repository 1.0, IRelationship::Delete() removes the relationship entirely so that the relationship no longer exists at the origin or the destination objects. In Repository 2.0, if we have navigated from the destination side, the relationship from the origin version to any other versions of the destination continues to exist after the deletion. If we have navigated from the origin side, the relationship from that version to all versions of the destination in the relationship is removed. Similar behavior holds true for IRelationshipCol::Remove() and ITargetObjectCol::Remove().

- In Repository 1.0, delete propagation stops at an object if it is the destination of some other relationship of the same type. In Repository 2.0, in addition to this condition, delete propagation stops at an unchangeable version (frozen or checked out to a different workspace) and versions that have incoming relationships (of any type) from a frozen origin (that is, no error).

SQL Tables

- The Repository 2.0 SQL tables are extensively revised for versioning. SQL views that match Repository 1.0 SQL queries executed on a repository database in which all objects have one version should work with no change.

- Repository 1.0 SQL queries executed on a repository in which multiple versions of objects exist will likely execute to completion, but their semantics should be reviewed in light of versioning. In certain situations multiple versions of the same object may be returned by the queries, which a Repository 1.0 application might not expect.

- The table RTblSites does not have the NextLocalID column in Repository 2.0.

- The table RTblClassDefs has a new column called VerPropDescs where the class definition is stored in Repository 2.0. The column PropDescs contains only null values and is no longer used. However, it is retained for compatibility.

Miscellaneous

The following table shows other differences between Repository 1.0 and Repository 2.0.

Description | V1 engine | V2 engine
IRepositoryItem::get_Item() | Out of range integer index returns EREP_BADPARAMS. | Out of range integer index returns DISP_E_BADINDEX.
IRelationshipCol::Insert() ITargetObjectCol::Insert() | Insert appends to the collection if the collection is a nonsequenced. | Insert fails for nonsequenced collections (EREP_COL_NOT-SEQUENCED) and destination collections (EREP_RELSHIP_ORGONLY).
IRelationshipCol::Move() ITargetObjectCol::Move() | Fails with EREP_RELSHIP_ ORGONLY for nonsequenced and destination collections. | Fails with EREP_COL_NOT-SEQUENCED for nonsequenced collections, and EREP_RELSHIP_ ORGONLY for destination collections.
IRepositoryObjectVersion::put_Name() | Error EREP_OBJ_NO-NAMING-RELSHIP is not added to the error queue. | Error REP_OBJ_NONAMING-RELSHIP is added to the error queue.
Unique naming collections: Item B with name "B" is added multiple times to a unique naming collection | Error code is EREP_RELSHIP_DUPENAME. | Error code is EREP_RELSHIP_EXISTS.
IRepositoryItem::get_Name() | Succeeds on a non-naming relationship (returns "0"). | Fails.
IRelationshipCol::get_Item() ITargetObjectCol:: get_Item() | Argument can be INTID, OBJID, Index, or Name. | Argument can be OBJID, Index, or Name.
ExecuteQuery() on SQL Server | Checks for INTID column in result set. | Accepts more than just INTID whenever implicit conversion is possible.
Refresh on object instances collection | Refreshes properties and then objects. | Refreshes objects and then properties.

#### Asynchronous Operation

Loading of object collections in response to IRepositoryODBC::ExecuteQuery() can be asynchronous. The calling thread should check to determine whether the load is complete. If the calling thread tries to read data, refresh the collection, or construct an enumerator while loading is in progress, it will be blocked until the load is complete.

#####

Flags

- For setting/clearing "async" option:

RODBC_RESET_OPTIONS = 1 // Reset all options
RODBC_ASYNCH = 2 // Asynchronous query execution

- For loading status of object:

>   READY = 1 // Loading is complete
>   INPROGRESS = 2 // Loading in progress
>   CANCELLED = 3 // Loading has been cancelled (by caller)
>   FAILED = 4 // Loading failed (reason unknown)

#####

New Interfaces

- IObjectCol2 -- inherits from IObjectCol.

> Additional methods:

> - LoadStatus: Obtains the load status of the collection.

> > ###### Signature

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

> > ###### Arguments

  piStatus
  [out, retval]
  One of READY/INPROGRESS/CANCELLED/FAILED.

> > ###### Return value

  S_OK if successful, EREP_BADPARAMS if no output argument is provided.

> - Cancel: Requests the cancellation of the ongoing load operation.

> > ###### Signature

> > HRESULT Cancel()

> > ###### Return value

>   S_OK.

- IRepositoryODBC2 -- inherits from IRepositoryODBC.

> Additional methods:

> - GetOption: Obtains the value of the load option.

> > ###### Signature

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

>   ###### Arguments

>   iOption
>   [in]
>   RODBC_ASYNCH.
>   psValue
>   [out, retval]
>   VARIANT_TRUE or VARIANT_FALSE, depending upon whether the RODBC_ASYNCH option has been set.

>   ###### Return value

>   S_OK if successful, EREP_BADPARAMS if any other option is specified.

> - SetOption: Sets the option for loading the collection. The async flag can be set if and only if the underlying database system supports the async operation.

> > ###### Signature

> > HRESULT SetOption(long iOption, VARIANT sValue)

> > ###### Input Arguments

> > iOption RODBC_ASYNCH and sValue TRUE sets the async mode of load.
> > iOption RODBC_ASYNCH and sValue FALSE clears the async mode.
> > iOption RODBC_RESET_OPTIONS resets the async mode of load.

> > ###### Return value

> > S_OK if successful, EREP_TYPE_COLMISMATCH if a value other than TRUE or FALSE is specified in sValue when iOption is RODBC_ASYNCH.

Other Changes

- Class ObjectCol supports both IObjectCol [default] and IObjectCol2.

- IObjectCol2::Refresh() asynchronously refreshes the object collection (reloads object collection and refreshes target objects) when the async mode is in effect. The calling thread should check to determine whether refresh is complete. If the calling thread tries to read data, refresh the collection, or construct an enumerator while refresh is in progress, it will be blocked until refresh is complete.

#### SQL and API Types Used in Property Definitions

The following two tables show the API types recognized by the Repository engine, as well as the SQL types. These values appear in the APIType and SQLType properties of a PropertyDef Object. For information on conversion between SQL and API types, please refer to the ODBC Programmer's Reference.

API TYPES RECOGNIZED BY ENGINE
API TYPE | VALUE
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 TYPE | VALUE
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

#### New Features

##### Properties

Two new properties have been added to the IRepository2 interface to indicate the version of the database file.

- MajorDBVersion

> ###### Signature

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

> ###### Arguments

> piMajorDBVersion
> [out, retval]
> The major version number of the first Repository engine version that introduced this database format.

- MinorDBVersion

> ###### Signature

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

> ###### Arguments

> piMinorDBVersion
> [out, retval]
> The minor version number of the first Repository engine version that introduced this database format.

##### Methods

A new method CreateObjectEx() has been added to the interface IRepository2. It creates the first version of a new Repository object of the specified type. The newly created version is assigned the object-version identifier passed in as an argument, unlike IRepository::CreateObject(), in which the Repository assigns the version ID. It has the following syntax:

> ######

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

> ######

> Arguments
> TypeID
> [in]
> It does the same work as IRepository::CreateObject
> ObjectID
> [in]
> It does the same work as IRepository::CreateObject
> ExtVersionID
> [in]
> This is the object-version identifier (20 bytes) to be assigned to the first version of the object
> ppRepObjVer
> [out]
> This is the IRepositoryObjectVersion pointer to the newly created version

### Known Limitations in Microsoft Repository 2.0

#### 1. Limitations related to interfaces and associated methods

IRepositoryObjectVersion

- MergeVersion(): Relationships are inserted at the end of the sequenced collection.

IRelationshipCol

and ITargetObjectCol

- Remove(): Removal from a sequenced collection does not update the collection sequence order.

IVersionAdminInfo

- VersionModifyTime(): Does not change when an origin relationship or target object collection is modified.
- ModifyByUser(): Does not change when an origin relationship or target object collection is modified.

IRepository2

- CreateObject(): Can only be called from the shared repository but not from a workspace. The workaround is to create the object through the central repository and include it in the workspace.

IClassDef

and IInterfaceDef

- ObjectInstances(): Not workspace scoped.

#### 2. Repository constants

In the Repository documentation, it is mentioned that the maximum length, in bytes, of a name that a relationship assigns to its destination object is 260 as defined by the constant RELSHIPNAMESIZE. This value is actually 249.

#### 3. Conventions for names

Names of relationships and objects must follow these conventions:

> 1. Names can be no longer than 249 characters.
> 2. Any characters can be used in a name.
> 3. The name can contain leading or trailing spaces. It can also be an empty string.
> 4. If the name is all spaces, it is treated as an empty string.

This applies to names used inside quotation marks or stored inside variables. For example, the following "IFolder" interface must meet these restrictions:

> oFolder("IFolder").FolderName

-or-

> oFolder(sIFolder).FolderName

where: sIFolder = "IFolder"

However, these guidelines are not accurate for names specified outside of quotation marks (such as property names or relationship collection names). For example, the relationship collection "RcFolderContains" below:

> oFolder("IFolder").RcFolderContains.Count

must adhere to the Microsoft Visual Basic naming guidelines, except that the limit is 127 characters instead of the 255 characters limit that Visual Basic allows.

#### 4. Stored Procedures

The stored procedure name for a table is generated by prefixing the table name with the string "R_i". Since table names are unique, this will generate unique stored procedure names. If the table name’s length is greater than MaxIdentifierLength-3, however, the table name generation algorithm fails. For this reason, a user may not supply a table name longer than MaxIdentifierLength-3. Supplying a longer name causes the error EREP_BADNAME.

When the user supplies no table name for an interface, the engine automatically generates the table name from the interface name. If the interface name, with the leading "I" stripped off, is less than MaxIdentifierLength-4, the interface name will be used as the table name. Otherwise, the interface name is truncated to MaxIdentifierLength-7, and a 4-character number (called a "uniqifier") is appended to the name to make it unique, before prefixing R_i.

The engine uses named arguments to call the stored procedures. A named argument starts with the "@" character and is not longer than MaxIdentifierLength. Therefore, the property names, which are also column names, must be no longer than MaxIdentifierLength-1.

MaxIdentifierLength’s are:

- 30 characters for SQL Server 6.5
- 128 characters for SQL Server 7.0

#### 5. Table Definitions

The following tables are not included in the Repository help file:

> - RTblSumInfo
> - RTblNamedObj
> - RTblVersionAdminInfo

These tables are explained below along with column names and data types.

RTblSumInfo

RTblSumInfo is an interface-specific table; its columns correspond to the properties exposed by the ISummaryInformation interface. By default, no class of the Repository Type Information Model implements ISummaryInformation. Thus the Repository database does not, by default, include the table RTblSumInfo. Instead, the Repository omits the table from the database to save space. However, as soon as you insert into the Repository any class that implements ISummaryInformation, Repository creates the table.

Column Name | Data Type | Description
IntID | RTIntID | The internal identifier of the class.
Z_BranchID_Z | RTBrID | Indicates the branch of the version graph containing the range to whose items the property values in this row apply.
Z_VS_Z | RTVerID | A version-within-branch identifier indicating the lower bound of the range to whose items the property values in this row apply.
Z_VE_Z | RTVerID | A version-within-branch identifier indicating the upper bound of the range to whose items the property values in this row apply.
Comments | RTLongString | A field used for comments.
ShortDesc | RTLongString | The description of the object.

RTblNamedObj

RTblNamedObj is an interface-specific table; its columns correspond to the properties exposed by the INamedObject interface. By default, no class of the Repository Type Information Model implements INamedObject. Thus the Repository database does not, by default, include the table RTblNamedObj. Instead, the Repository omits the table from the database to save space. However, as soon as you insert into the Repository any class that implements INamedObject, Repository creates the table.

Column Name | Data Type | Description
IntID | RTIntID | The internal identifier of the class.
Z_BranchID_Z | RTBrID | Indicates the branch of the version graph containing the range to whose items the property values in this row apply.
Z_VS_Z | RTVerID | A version-within-branch identifier indicating the lower bound of the range to whose items the property values in this row apply.
Z_VE_Z | RTVerID | A version-within-branch identifier indicating the upper bound of the range to whose items the property values in this row apply.
Name | RTLongString | The name of the object.

RTblVersionAdminInfo

RTblVersionAdminInfo is an interface-specific table; its columns correspond to the properties exposed by the IVersionAdminInfo interface. By default, no class of the Repository Type Information Model implements IVersionAdminInfo. Thus the Repository database does not, by default, include the table RTblVersionAdminInfo. Instead, the Repository omits the table from the database to save space. However, as soon as you insert into the Repository any class that implements IVersionAdminInfo, Repository creates the table.

Column Name | Data Type | Description
IntID | RTIntID | The internal identifier of the class.
Z_BranchID_Z | RTBrID | Indicates the branch of the version graph containing the range to whose items the property values in this row apply.
Z_VS_Z | RTVerID | A version-within-branch identifier indicating the lower bound of the range to whose items the property values in this row apply.
Z_VE_Z | RTVerID | A version-within-branch identifier indicating the upper bound of the range to whose items the property values in this row apply.
VersionCreateTime | Date/Time | The time the version has been created.
VersionModifyTime | Date/Time | The time the version has been modified.
CreateByUser | RTLongString | The user who created the version.
ModifyByUser | RTLongString | The user who modified the version.

#### 6. Other Limitations

- Migration Wizard (MigRepV2.exe), Repository Browser (Repbrows.exe), and Visual Component Manager (VCM) do not support file DSNs (Data Source Names). These tools only work against a DSN of type Access or SQL Server.

- In the Migration Wizard, if you work against a DSN of the type SQL Server, you will be asked to enter a user name and a password unless the DSN is configured using the Windows NT authentication option (in the ODBC Data Source Administrator).

- In the topic "Examples of Merging Versions," there is an inaccuracy in the second graph. The properties of the version V8 should change, after the merge, from (Large, Red, null) to (Medium, Red, null).

- The documentation for the CollectionDefFlags enumeration did not mention the following flag:

  COLLECTION_NEWORGVERSIONSDONOTPARTICIPATE = 64

  This flag is related to another flag in the same enumeration:

  COLLECTION_NEWORGVERSIONSPARTICIPATE = 32

> The two flags have opposite meanings. Thus, they cannot both be set at the same time. However, since the default setting for each of them is unset, it is possible for both flags to be unset at the same time. If both flags are unset, the Repository operates as if the COLLECTION_NEWORGVERSIONSPARTICIPATE flag is set. That is, during the creation of a new version of a repository object, Microsoft Repository does copy new origin collections from a predecessor creation version to a successor version.

- If a SQLSize is set to a value greater than 65535, the engine divides the entered number by 65536 and sets SQLSize to the value of the remainder of the division, but no error is returned.

- In the help topic "The Migration Algorithm" there are references to two tables, RTblRelColPairs and RTblTimestamp. In the Repository 2.0 database, the first table does not exist, and the second table has been replaced by RTblVersionAdminInfo.

#### For More Information

You can go to these sources for more information about Microsoft Repository:

- Check for the latest news on the Microsoft Repository Web site (http://www.microsoft.com/repository). You can also download Repository documentation from this site.
- In the Microsoft Visual Studio 6.0 documentation, you will find the Repository Programmer's Guide, Repository Reference, Repository Browser, and Converting Repository 1.0 Databases. To locate these documents start at the top and follow this path:

  > > MSDN Library Visual Studio 6.0
  > > Visual Studio Documentation
  > > Component, Design, and Analysis Tools
  > > Microsoft Repository 2.0 Documents

- In the Microsoft Visual Basic 6.0 documentation, you will find Repository Programmer's Guide for Visual Basic and The Microsoft Repository Visual Basic Add-in Reference. To locate these documents start at the top and follow this path:

  > > MSDN Library Visual Studio 6.0
  > > Visual Basic Documentation
  > > Using Repository with Visual Basic