Results 1 to 5 of 5
  1. #1
    Join Date
    Jan 2003
    Posts
    2

    Unanswered: SQL5042N One of the communication protocol server support processes failed to start

    I have a SQL Server 2000 job using an open query with a link server to DB2. The job was running successfully until the gateway was upgraded. The DB2 client version is "DB2 v8.1.10.812", "s050811", "WR21362", and FixPak "10".

    The job executes a DTS package which contains a stored procedure which uses open query to call a linked server and retrive data from DB2.

    When I execute the stored procedure in pieces in Query Analyzer the steps work. When I execute them all together the stored procedure fails with the following message.

    OLE DB provider 'IBMDADB2' reported an error.
    [OLE/DB provider returned message: SQL5042N One of the communication protocol server support processes failed to start up.
    ]
    OLE DB error trace [OLE/DB Provider 'IBMDADB2' ITransactionJoin::JoinTransaction returned 0x80004005: ].

    The server is Windows 2003 and everything has been turned on for MSDTC. The link is configured to run in process. Any help would be appreciated.

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    The error message:
    Quote Originally Posted by DB2 OLEDB Provider
    SQL5042N One of the communication protocol server support processes failed to start up.
    ...is generated by the DB2 Connect code that provides your DB2 OLEDB driver. It is reported by SQL Server from the DTS package, but the error occured completely outside of SQL Server.

    About ninty five percent of the time, I've found this to be a problem with the MS-DTC configuration. You can change that configuration by running DCOMCNFG.EXE from the Start | Run dialog box on the machine that runs your SQL Server.

    The other five percent of the time it seems to be a broken DB2 Connect installation, but a reinstall has always corrected that for me.

    -PatP

  3. #3
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    It is possible that during the upgrade the gateway terminated the ports used by MSDTC (135, 1024-5000). Check that with your netadmin.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  4. #4
    Join Date
    Jan 2003
    Posts
    2
    The MSDTC is configured as specified in this article except that the except the Windows firewall service is not running (and I don't think it is supposed to be). I will have them check that the port was not disabled.

    http://support.microsoft.com/?kbid=873160

    If you click the link it works, also if you execute a query. It just doesn't work in the stored procedure with a begin and end transaction.

  5. #5
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    The link you provided does not reflect your problem.

    The reason why individual statements work is because by themselves they do not get escalated to an implicit distributed transaction, while a stored procedure qualifies to be escalated to a distributed transaction. If MSDTC cannot talk to both ends of the transaction on 135 (for transaction messages) and on any one of the ports in the range from 1024 through 5000 (for TDS packets), - you get the error that you posted. It has nothing to do with MSDTC configuration, especially since there was no change made to it. Inability of MSDTC to enlist or to add a statement into a transaction is in its inability to negotiate the transport for TDS packets of pre-transaction negotiation (135). If the gateway upgrade resulted in this situation, - you answer lies somewhere where your netadmin sits
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •