SAP Business One DI API Connection Troubleshooting Checklist
This checklist walks an SAP Business One developer or administrator through the checks that resolve most DI API (SAPbobsCOM) connection failures on SAP Business One 9.x and 10.0, for SQL Server and HANA. Tick each item, note what you changed, and export the result to attach to a support ticket.
0 of 35 items complete
10 critical items still open - these are the highest-risk gaps.
1. Installation and version match
2. Company connection properties
3. Error handling and diagnosis
4. Environment, network and licensing
5. Runtime stability
Work top to bottom: most Connect failures are fixed in groups 1 and 2. Critical items are the ones that cause the majority of failed connections after installs and upgrades.
Stuck on a DI API connection error?
Send us your error code, DI API and server versions and process bitness, and we will tell you which checks to run next.
Optional. The tool and every export work without this. No spam.
How to use it
Start with the installation group, because a version or bitness mismatch makes every later check misleading. Note the DI API version shown in Programs and Features and compare it with the server version in the SLD Control Center or Help > About in the B1 client. Then confirm the bitness of the process that calls the DI API: a console app built as x86, an IIS app pool with 32-bit applications enabled, or an integration platform agent all count. Only then move to the Company properties. Record the exact error code and message from GetLastError on the first failed attempt, since later retries can return a different, less useful error. Export the checklist with your notes when you escalate to your partner or SAP.
Where the connection settings live
Everything the DI API needs is a property on the SAPbobsCOM.Company object: Server, CompanyDB, DbServerType, UserName, Password, UseTrusted, DbUserName, DbPassword, LicenseServer, SLDServer and language. The correct values are already registered in the System Landscape Directory for the company, so the safest approach is to read the server address and port from the SLD Control Center (on 9.x and 10.0 it is normally reached on port 40000) and copy them. CompanyDB is the database name of the company, which you can also see in the SBO-COMMON company list or in the company selection window. UserName is a B1 user, not a database login. Keep these values in configuration, not in code, so a server move does not need a rebuild.
- Server: as registered in SLD
- DbServerType: BoDataServerTypes member for your engine
- CompanyDB: database name, not display name
- UserName / Password: B1 user
- LicenseServer / SLDServer: host:port
Worked example: -111 after a 10.0 patch upgrade
A nightly import service starts failing with -111 'Failed to connect to SBO-Common' the morning after the server is patched. Group 1 shows the integration server still has the DI API from the previous patch, so it is upgraded; setup then reports that the previous version uninstallation failed. The old DI API is removed from Programs and Features, the machine is rebooted and the leftover folder is renamed, after which setup completes. The service still fails because it is compiled as x86 and only the 64-bit DI API was reinstalled. Installing the 32-bit DI API of the same patch fixes the connection. The team then adds DI API version and process bitness to the startup log so the next upgrade is a five minute check.
Version differences and gotchas
SQL Server and HANA use different DI API builds and different DbServerType values; a SQL build pointed at HANA returns a database type not supported error. New SQL Server versions are added to BoDataServerTypes over time, so an old DI API may not have the member your server needs. Older releases used a separate license server, classically on port 30000, while 9.x and 10.0 route licensing through the SLD and License Manager. Releases that manage database credentials in the SLD often accept empty DbUserName and DbPassword. The DI API is single-threaded COM and leaks memory if objects are not released, which is why long-running web or multi-threaded integrations usually move to the Service Layer. Always confirm error code meanings against SAP notes for your release.
Frequently Asked Questions
What does DI API error -111 failed to connect to SBO-Common mean?
The DI API could not open the SBO-COMMON database on the server you gave it. Typical causes are a wrong DbServerType, wrong database credentials or Server value, a DI API patch level that differs from the server, or a 32-bit process using a machine that only has the 64-bit DI API (or the reverse). Check those in that order.
Do I need the 32-bit or 64-bit SAP Business One DI API?
The one that matches the process calling it. A program built for x86, or an IIS app pool with 32-bit applications enabled, needs the 32-bit DI API; an x64 process needs the 64-bit DI API. You can install both side by side. Each must be the same version and patch as the B1 server.
How do I fix previous version of SAP Business One DI API uninstallation failed?
Close the B1 client and anything using the DI API, uninstall the existing DI API from Programs and Features, reboot, and confirm the old DI API folder under Program Files (or Program Files (x86) for 32-bit) has been removed or renamed. Then run the new setup as administrator. If it still fails, ask your partner about the SAP note for your release.
Which port do I use for LicenseServer in SAP Business One 10.0?
On 9.x and 10.0 the SLD and License Manager normally listen on port 40000, so LicenseServer and SLDServer are usually set as host:40000. Older releases used a standalone license server, classically on port 30000. Check the address shown in your SLD Control Center, because a landscape can be configured with a different port.
If you want your team to ask SAP Business One questions in plain English on your own servers, we can set up a private AI layer that reads B1 through the Service Layer or SQL with read-only access.
Related Tools
SAP Business One DI API Sales Order Code Generator (C#)
Fill in connection and order details to get a C# DI API skeleton that connects, adds a sales order and reports errors.
Developer ToolsSAP Business One Service Layer Request Builder
Fill in host, company and item details and get ready-to-paste Service Layer requests for login, item query, sales order and production order.
Developer ToolsSAP B1 Service Layer Sales Order JSON Generator
Fill in server, company database, customer and line details to get ready-to-test Login and sales order POST requests for the Service Layer REST API.
SAPSAP Business One Database Tables Reference
Searchable lookup of the core SAP Business One tables, with the matching row table and what each one stores.
More Developer Tools tools
See all- SAP Business One T-SQL to HANA SQL Query Conversion Reference
- SAP Business One AR Aging SQL Query Generator (SQL Server and HANA)
- SAP Business One Formatted Search (FMS) Query Generator
- SAP Business One Pending Approvals Query Generator (OWDD, WDD1)
- SAP Business One Service Layer $batch Request Generator
- SAP Sales Order ABAP SELECT Generator (VBAK, VBAP, VBFA)
- SAP Sales Order Create BAPI ABAP Generator (BAPI_SALESORDER_CREATEFROMDAT2)
- SAP ABAP Open Items SELECT Generator
- SAP ACDOCA SQL Query Generator
Keep exploring
Free tools
- SAP Business One DI API Sales Order Code Generator (C#)Fill in connection and order details to get a C# DI API skeleton that connects, adds a sales order and reports errors.
- SAP Business One Production Order ChecklistA step-by-step checklist for creating, releasing, issuing to, receiving from and closing a production order in SAP Business One.
- SAP Business One Go-Live Cutover ChecklistA cutover checklist for taking a Business One company live: freeze, balances, stock counts, users, integrations and hypercare.
Integrations
- How to connect Claude to SAP Business OneConnect Claude to SAP Business One using MCP over the Service Layer, choose between the Anthropic API, AWS Bedrock or Vertex AI, or keep data on-prem.
- How to use ChatGPT with SAP Business OneUsing ChatGPT with SAP Business One: exports versus live Service Layer access, custom GPT actions, enterprise data controls, and when a private model fits better.