Developing SQL-DMO Applications Using C or C++

A 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, in this case, SQL-DMO globally unique identifiers (GUIDs) is added to your application unit. 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 CoUninitialize and 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)
        OleUninitialize();

    // 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.