Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Developing SQL-DMO Applications Using C or C++

This feature will be removed in the next version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

SQL Server Database Management Objects (SQL-DMO) has been removed from SQL Server 2008 R2 Express and the SQL Server 2008 R2 Feature Pack. SQL-DMO also does not support Database Engine features introduced after SQL Server 2000. We recommend that you modify applications that currently use this feature as soon as possible. If you must support SQL-DMO, install the Backward Compatibility Components from the SQL Server 2008 Feature Pack from the Microsoft Download Center. Do not use SQL-DMO in new development work; use SQL Server Management Objects (SMO) instead. You can obtain the SMO documentation by installing SQL Server 2008 R2 Books Online.

A SQL Distributed Management Objects (SQL-DMO) application built using C or C++ follows the same general guidelines as any application using a COM object library. The application will:

  • Initialize class identifiers as part of application construction.

  • Initialize COM on application start.

  • Use the SQL-DMO object library during application execution.

  • Free COM on application exit.

Initializing class identifiers is performed one time, at global scope, for an application unit (.exe or .dll). Use the supported #include <Initguid.h> method for identifier initialization, as in:

#include <initguid.h>
#include <sqldmoid.h>
// Other includes, such as sqldmo.h

When initializing class identifiers, read-only data is added to your application unit, in this case, SQL-DMO globally unique identifiers (GUIDs). Other modules, including Sqldmoid.h, are not initialized. Those modules contain declarations, resolved by the linker, for data external to the module.

Errors in SQL-DMO class identifier initialization are reported as linker errors. If an unresolved external symbol error occurs on application unit linking, the class identifiers have not been initialized. Include Initguid.h in a likely module in your application unit. During linking, if you receive a multiply-defined symbol error with a SQL-DMO symbol specified, then SQL-DMO class identifiers have been initialized more than one time. Remove the initialization from all modules but one.

COM initialization is performed through any of a number of mechanisms. For some applications, the CoInitialize function is used. Other applications, for example, applications using compound document support or other functions of the OLE library, use OleInitialize, which itself calls CoInitialize.

Remember that initializing COM can fail. If COM initialization fails, SQL-DMO is unavailable. An application should be built to handle this abnormal condition gracefully.

The functions CoUninitializeand OleUninitialize free COM. When using CoInitialize to initialize COM, use CoUninitialize to free COM. Likewise, use OleUninitialize to free OLE and COM when OleInitialize is used by the application. For example:

BOOL OnInitInstance()
    m_bCOMAvailable = SUCCEEDED(OleInitialize(NULL));
    // Other initialization...
    return (TRUE);

    // The remainder of the application uses SQL-DMO.

void OnExitInstance()
    if (m_bCOMAvailable)

    // Other dynamic resource freeing...

Application development frameworks may support other, easy-to-use methods. For example, the MFC function AfxOleInit handles both OLE and COM initialization. Freeing COM and OLE is performed by framework code included as your application is built, so there is no need to free COM explicitly when using MFC AfxOleInit.

Community Additions

© 2015 Microsoft