Skip to Content

Di Server Invalid database type dst_MSSQL2014

Hi All,

I'm trying to connect to SQL 2014 using the v9.1 PL04 DI Server. However I am getting an invalid database type message returned from the DI Server. I am using the value dst_MSSQL2014 which is the value used in the DI API which works successfully.

For all previous SQL versions the value passed to the DI Server exactly mirrors that of the BoServerTypes enumeration value name. It would appear as if this is not the case for SQL 2014. Can anyone tell me what the value should be?

Below is the login request that I am sending to the DI Server and the response that I am receiving.

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
     <env:Body>
          <Login xmlns="http://www.sap.com/SBO/DIS">
               <DatabaseServer xmlns="">SAPv9DOT1TEST</DatabaseServer>
               <DatabaseName xmlns="">SBODEMOGB</DatabaseName>
               <DatabaseType xmlns="">MSSQL_2014</DatabaseType>
               <DatabaseUsername xmlns="">sa</DatabaseUsername>
               <DatabasePassword xmlns="">Pa55w0rd</DatabasePassword>
               <CompanyUsername xmlns="">manager</CompanyUsername>
               <CompanyPassword xmlns="">reganam</CompanyPassword>
               <Language xmlns="">ln_English</Language>
               <LicenseServer xmlns="">sapv9dot1test:30000</LicenseServer>
          </Login>
     </env:Body>
</env:Envelope>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
     <env:Body>
          <env:Fault>
               <env:Code>
                    <env:Value>env:Sender</env:Value>
                    <env:Subcode>
                         <env:Value>-8008</env:Value>
                    </env:Subcode>
               </env:Code>
               <env:Reason>
                    <env:Text xml:lang="en">Invalid database type</env:Text>
               </env:Reason>
               <env:Detail>
                    <Param>ServerType</Param>
                    <Value>dst_MSSQL2014</Value>
                    <DatabaseType>dst_MSSQL2014</DatabaseType>
                    <Command>Login</Command>
               </env:Detail>
          </env:Fault>
     </env:Body>
</env:Envelope>

Thanks,

Darren

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Jan 07, 2015 at 03:54 PM

    Hi,

    Here is a list of the servertype from SBO9.1 PL04

    dst_MSSQL 1 Microsoft SQL Server 2000 (Not Supported from 8.8)

    dst_DB_2 2 DB2 (Not Supported from 8.8)

    dst_SYBASE 3 Sybase (Not Supported from 8.8)

    dst_MSSQL2005 4 Microsoft SQL Server 2005

    dst_MAXDB 5 MaxDB (Not Supported from 8.8)

    dst_MSSQL2008 6 Microsoft SQL Server 2008

    dst_MSSQL2012 7  

    dst_MSSQL2014 8  

    dst_HANADB 9

    MSSQL2014 is 8,

    If you use 8 it should work.

    Regards

    Ad

    Add comment
    10|10000 characters needed characters exceeded

  • Jan 07, 2015 at 03:49 PM

    Hi Darren,

    I had a look and it seems they ( SAP ) forgot to implement MSSQL 2014 support for DIS :

    C:\Program Files (x86)\SAP\SAP Business One ServerTools\DI_Server\Interface\InterfaceRep.xml

    <BoDataServerTypes PropName="BoDataServerTypes" TypeName="BoDataServerTypes" isUserType="Y" isWritable="Y">
        <dst_MSSQL>1</dst_MSSQL>
        <dst_DB_2>2</dst_DB_2>
        <dst_SYBASE>3</dst_SYBASE>
        <dst_MSSQL2005>4</dst_MSSQL2005>
        <dst_MAXDB>5</dst_MAXDB>
        <dst_MSSQL2008>6</dst_MSSQL2008>
        <dst_MSSQL2012>7</dst_MSSQL2012>
        <dst_HANADB>9</dst_HANADB>
    </BoDataServerTypes>
    

    I don' have a SQL 2014 running but I don't think you made a mistake. I think you have to get in touch with support.

    regards,

    Maik

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Maik,

      I have tried the same tests this morning and found this to work. I am intending on raising the issue with support as I feel that manually changing the InterfaceRep.xml file is not something that we should be doing ourselves.

      I think as a temporary workaround I can live with passing the integer value for the database type until it is fixed.

      Thanks,

      Darren