Di Server Invalid database type dst_MSSQL2014

[darren_blaby]

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

[AdKerremans · Accepted solution]

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

[maik_delly · Accepted solution]

Hi Ad,

this is what the SDK help file states - but it only applies for DI API.

regards,

Maik

[maik_delly]

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

[maik_delly]

Hi Darren,

I experiemented a little:

If you use :

<DatabaseType xmlns="">8</DatabaseType>  

it should work.

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

<dst_MSSQL2014>8</dst_MSSQL2014>  

regards,

Maik

[darren_blaby]

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