cancel
Showing results for 
Search instead for 
Did you mean: 

DI "Database server type not supported" after 8.82->9.0 upgrade

Former Member
0 Kudos

Hello,

We've been using some in-house applications using the DI API for a couple of years, but after our upgrade from B1 8.82 to 9.0 (PL 11), I'm getting the "Database server type not supported" when connecting to the company from client PCs.

I did check other posts mentioning this error (see below; tried the suggested solutions and checks - moving everything to the server is not an option; the applications run on several client PCs).

Important points:

1 - License server, B1 server, and SQL 2008 R2 server run on the same Windows 2008 R2 Server

2 - Running the apps on the server works, only fails from client machines (same workgroup as the server)

3 - Same app worked fine with B1 8.82

4 - We did reinstall (several times) the B1 DI API on the clients (some client PCs have the full B1 client, some only the DI API), same version installed on the server

5 - MS SQL Native Client was also reinstalled several times on the clients, matches version of SQL Server and Native Client on the server (10.52.4000.0).

6 - Tried referencing the server/license server both by name and by ip in the app, also tried switching this in C:\Program Files (x86)\SAP\SAP Business One DI API\Conf\b1-local-machine.xml

7 - DI API seems to connect with the server (there's traffic on port 30000 when the application tries to connect, and if I use wrong values for the license server adress/port in the application, it hangs trying to connect - not getting to the "Database server type not supported" message).

8 - MS SQL Native client is working; the same app also queries (select only) the server using ODBC through the native client, and this still works.

9 - Tried turning Windows firewall off both on client and server, same thing.

10 - Connection properties are:

Server: 192.168.168.150 (also tried name)

LicenseServer:  192.168.168.150:30000 (also tried name)

CompanyDB: (our db name)

UserName: (valid user)

Password: (password)

language: (3, english)

UseTrusted: false (also tried true, with/out db user/pass)

DbServerType: (6, MSSQL2008) (also tried from 0 to 7, 0 returns "No database server type specified", all others return "Database server type not supported")

DbUserName: sa

DbPassword: password

11 - Windows Server and Clients are 64 bits, but SAP B1 and DI API are 32, application using the DI is also 32. MS Native Client is 64 (does not allow 32 to be installed on the 64bit client PCs). Tried installing the 64bit DI API, but then the 32bit application cannot initialize the ActiveX component.

Again, everything worked fine before upgrading from 8.82 to 9.0, and still works if ran on the server.

May or not be related: Crystal Reports cannot list the databases after the upgrade to 9.0 too.

Could this be related to SLD? My SDK 9.0 help files still refers to the 2007 DI API in the "Connecting to SAP Business One Database", so maybe there is something that needs to be changed related to SLD or something else for 9.0 which is not in the help yet?

Thanks in advance for any help!

Joao S Veiga

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Ok, what I had to do was to create a helper executable with a "requireAdministrator" manifest, and call it from my main application when I need to use the DI.

I still use UI to get the DI company for all operations but create bin locations ("manager" is required). For creating bin locations, I call the helper app, which pops up windows UAC, and if the user has Administrator rights in the PC, s/he can proceed.

Not ideal, but better than running the whole app as admin, or having users logon as manager.

Former Member
0 Kudos

In case someone gets here with similar problems:

I have since been using UI to get a DICompany (which requires the user to have an open B1 session).

I just went back to the issue, and found that if I run my application "as Administrator", it works Ok.

Something changed between 8.8 and 9.0 that it now requires admin rights when running on Windows 8 so be able to connect to the database.

Still investigating a way to overcome this.

Former Member
0 Kudos

Additional information:

The client PCs I've been trying to use the app from are Windows 8 64bits (which also used the app with B1 8.82).

Now I tried on an old Vista 32bits, and it WORKS TOO.

Maybe the problem is related to the DI API 9.0 and mixing 32bits app/api with 64bits SQL Client on a 64bits WIndows 8? Somehow it works on the Windows Server 2008 R2 64bits though.

Joao

maik_delly
Active Contributor
0 Kudos

Hi Joao,

you really made your way through the forum - but what I am missing in your list ( which is a good roundup  of possible problems ) : Did you reference the new SAPbobsCOM90.dll ( 9.0)  in your project ?

regards,

Maik

Former Member
0 Kudos

Thank you Maik,

actually I didn't... I'm using C++ on Qt, which has no reference settings like in Visual Studio (why not VS? About 40k lines of code which we had since before we deployed B1, and was working with B1 since when we deployed B1 in 2008)

I have to either simply use the name (and I only have the 9.0 DI API installed) or the CLSID directly, like in:

   cmp = new QAxObject("SAPbobsCOM.Company", this);

OR

   cmp = new QAxObject("{632F4591-AA62-4219-8FB6-22BCF5F60090}", this);

OR

   cmp = new QAxObject("SAPbobsCOM.Company.90.0", this);

THEN

   cmp->setProperty("Server", "192.168.168.150");

   cmp->setProperty("LicenseServer", "192.168.168.150:30000");

   cmp->setProperty("CompanyDB", db);

   cmp->setProperty("UserName", user);

   cmp->setProperty("Password", pass);

   cmp->setProperty("language", 3); //english

   cmp->setProperty("UseTrusted", false);

   cmp->setProperty("DbServerType", 6); //MSSQL2008

   cmp->setProperty("DbUserName", dbuser);

   cmp->setProperty("DbPassword", dbpass);

   rc = cmp->dynamicCall("Connect()").toInt();

The actual COM is working, as running on the server goes Ok, and when running in the client I can see the client machine "talking" to the server at port 30000 when it gets to "Connect()".

For some reason, when running in the client, it looks like the DI is not accepting that the MS SQL Client is valid.

Thanks again,

Joao S Veiga


maik_delly
Active Contributor
0 Kudos

Hi Joao,

I don't have an environment to test this c++ connection. But  it looks good to me.

Since the error message ( Database server type not supported ) is quite clear it should be imho one of the following :

- you are not having a MSSQL 2008 Server

- your SQL Server is not  reachable at 192.168.168.150 ( is it a new server installation ? ), maybe it is an SQL instance  like :  Server\SQLinstance )

I just read your addition : this is a highly possible - there are a lot of 32/64 bit issues in SBO 90. In .net I would advice you to build your application in x86 mode and use only 32 bit DI API.

regards,

Maik

Former Member
0 Kudos

Thank you again Maik,

The MS SQL 2008 R2 is up and running (since 2008), B1 9.0 client runs on the client PCs and accesses it, as well as our application via ODBC, and even our application from the Vista 32 PC via ODBC and DI - the app only uses the DI when it needs to write to B1 tables, for example for managing projects (OPRJ), placing Work Orders (one of the app's functions is MRP, it recommends and places the OWORs), and adding man-hour costs (from android qrcode readers) to the WOs. All PCs could do it before the 8.82->9.0 upgrade.

The app is built for x86, and the DI API is x86, but the SQL Native Client installer does not allow the installation of the 32 bit version in a Win8 64. That might be the problem.

I connected via DI using VBA (Excel 2013 32bits) from a Windows 8 64, so I'm afraid 9.0 broke the 32-64 thing for the unsupported integration with Qt only, which gives me slim hopes of attention from SAP developers.

For now, the workaround we could find is to get the Company object using the UI API GetDICompany (which requires that a B1 client session be opened when the DI operation is needed). Not ideal, but works until (hopefully) the issue is fixed. Another ugly hack I can think about is to create specific "adapters" for the DI operations wee need with VS and call them from the Qt app.

best regards, and thanks again

Joao