# SAP Business One DI API Connection Troubleshooting Checklist > Source: https://netray.co/tools/sap-b1-di-api-connection-troubleshooting-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Work through installation, Company connection properties, error handling, environment and runtime checks when an SAP Business One DI API Connect call fails. ## Category developer ## Erp SAP Business One ## Audience - SAP Business One developer - Add-on developer - ERP administrator - Integration engineer ## Tool **Kind:** checklist **Groups:** #### 1. Installation and version match **Items:** **Text:** DI API version and patch level are exactly the same as the SAP Business One server (Help > About in the client, or the SLD Control Center). A DI API one patch behind or ahead is the most common cause of a failed Connect after an upgrade. **Critical:** true **Text:** DI API bitness matches the calling process: a 32-bit (x86) program needs the 32-bit DI API, a 64-bit (x64) program needs the 64-bit DI API. Check the build target in Visual Studio; 'Any CPU' runs as 64-bit on a 64-bit OS unless 'Prefer 32-bit' is ticked. **Critical:** true Both bitnesses installed side by side if you run both 32-bit and 64-bit callers on the same machine (64-bit installs under C:\Program Files\SAP\SAP Business One DI API, 32-bit under C:\Program Files (x86)\SAP\SAP Business One DI API). Installer taken from the installation package of the same version as the server (32-bit and 64-bit packages are separate), not from an older download kept on a share. Setup run as a local administrator, with the SAP Business One client and any add-on host closed so no file is locked during upgrade. **Text:** If setup reports that the previous version of SAP Business One DI API uninstallation failed: remove the old DI API from Programs and Features first, reboot, then check that the old DI API folder is gone (rename or delete leftovers) before running the new setup again. **Critical:** true COM registration present: a quick test creating the SAPbobsCOM.Company object (ProgID SAPbobsCOM.Company) from a small script or console app succeeds. A 'class not registered' error means the DI API for that bitness is missing or not registered. Project reference points at the DI API type library of the installed version (Interop.SAPbobsCOM rebuilt after the upgrade), not a stale interop DLL copied from another machine. #### 2. Company connection properties **Items:** **Text:** Company.Server holds the database server exactly as it is registered in the SLD for that company (SQL Server name or name\instance, or the HANA host and SQL port). Copy it from the SLD rather than retyping. **Critical:** true **Text:** Company.DbServerType set with the BoDataServerTypes enum member for the actual engine and version (for example dst_MSSQL2016, dst_MSSQL2017, dst_MSSQL2019 or dst_HANADB), not a hard-coded integer. **Critical:** true The enum member you need exists in your DI API build. Newer SQL Server versions are added to BoDataServerTypes in later releases; if the member is missing, the DI API is too old for that SQL Server. Company.CompanyDB is the database name of the company (for example SBODEMOUS), not the company display name shown in the login screen. **Text:** Company.UserName and Company.Password are an SAP Business One user (for example manager), not a SQL or HANA database login. **Critical:** true Company.UseTrusted set to false when you use SQL authentication, true only if you deliberately rely on Windows authentication for the database. Company.DbUserName and Company.DbPassword supplied for SQL Server when UseTrusted is false. On releases where the SLD manages database credentials they can often be left empty; test both ways if Connect fails. Company.LicenseServer (and Company.SLDServer on releases that expose it) in host:port form, pointing at the license / SLD service. On 9.x and 10.0 the SLD and License Manager normally listen on port 40000; 30000 was the classic license server port on older releases. Confirm in your landscape. Company.language set (for example BoSuppLangs.ln_English) so error messages come back in a language your log readers understand. #### 3. Error handling and diagnosis **Items:** **Text:** Treat any non-zero return from Company.Connect() as a failure and immediately call Company.GetLastError(out errCode, out errMsg) before any other DI API call overwrites it. **Critical:** true Log the error code, error message, Server, CompanyDB, DbServerType, LicenseServer, DI API version and process bitness on every failed attempt, never the passwords. -111 'Connection to SBO-Common has failed': check DbServerType, database credentials, Server value, a DI connection license for the B1 user, and bitness first; the DI API could not reach the SBO-COMMON database. -132 'Error during SBO user authentication': the B1 user name or password is wrong, the user is locked, or the DI API and server patch levels differ. Log in with the same user in the B1 client to separate the two. 'Database server type not supported': the DbServerType value is not valid for the installed DI API, or a SQL Server DI API is being pointed at HANA (or the reverse). Check Company.Connected before using the object, and call Company.Disconnect() in a finally block so failed runs do not leave sessions open. #### 4. Environment, network and licensing **Items:** **Text:** Firewall allows the client machine to reach the database port (SQL Server default 1433 or the named instance port, or the HANA SQL port) and the SLD / license port. **Critical:** true SQL Server client connectivity component required by your B1 release is installed on the DI API machine (check the B1 platform support matrix for which driver your patch expects). For HANA, the SAP HANA client of the same bitness as the DI API is installed and its version is supported for your B1 release. The Windows account running the integration (service account, IIS app pool identity, scheduled task user) has read access to the DI API folder and can write to the user temp folder the DI API uses. The B1 user used for Connect has a license assigned in License Administration that allows this kind of access. Licensing for integrations and indirect use varies by contract; confirm with your partner. The same B1 user is not used by several unattended processes at once; give each integration its own user so sessions and license use are traceable. The database and SLD host names you put in Server and LicenseServer resolve from the integration host (a name that works on the B1 server itself, or '(local)' / 'localhost', may not resolve or may point at the wrong machine from another host). #### 5. Runtime stability **Items:** **Text:** Release every COM object you create (Recordset, Documents, BusinessPartners and so on) with Marshal.ReleaseComObject when done, especially inside loops, to stop memory growth and locked sessions. **Critical:** true **Text:** One Company object per thread. The DI API is a COM component designed for single-threaded use; do not share a connected Company across threads or concurrent web requests. **Critical:** true Reuse one connection for a batch of work instead of Connect and Disconnect per document; connecting is slow. Wrap multi-document writes in Company.StartTransaction and Company.EndTransaction(BoWfTransOpt.wf_Commit or wf_RollBack) and check Company.InTransaction on errors. For web applications, multi-threaded services or integrations from non-Windows hosts, consider the Service Layer (REST/OData) instead of the DI API. **Scoring Note:** 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. ## Content **Intro:** 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. **Sections:** #### How to use it **Body:** 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 **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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. **Cta:** 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. **Faq:** #### What does DI API error -111 failed to connect to SBO-Common mean? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms sap business one di api connection, sap b1 di api error code, sap business one di api installation failed, previous version of sap business one di api uninstallation failed, sap business one di api 64 bit download, sap business one di api 10.0, sapbobscom company connect, failed to connect to sbo-common --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json