Sometimes a report that has always worked suddenly fails with an error like:
In the cases covered here, the reports and the databases themselves were fine. The failures came from the database-driver environment on the machine running the report: a required driver or provider was missing, the wrong version was installed, an update damaged its installation, or the installed version was incompatible with the report it had to serve.
One note on wording before we start: in this article, "database driver" covers both ODBC drivers and OLE DB providers. They serve a similar purpose, but they are separate connection technologies and are not interchangeable. A report built on ODBC uses a DSN and an ODBC driver, while a report built on OLE DB asks for a provider by its registered name, such as SQLNCLI11 or Microsoft.ACE.OLEDB.12.0.
The 32-bit edition of Report Runner used in these examples needs the 32-bit version of each database driver and provider, even on 64-bit Windows (32-bit DSNs are managed in the 32-bit ODBC Administrator, C:\Windows\SysWOW64\odbcad32.exe). Many of these 32-bit drivers are getting harder to find because vendors have removed the downloads from their websites. We keep an archive of original legacy driver installers, so if you need one that is no longer available from the vendor, contact us.
Below are six case studies of real support incidents (details changed to protect customer information) showing how these problems look and how they were fixed.
---
What the log file showed ("compressed" log highlighting key lines we look at):
01/01/2001 01:01:01 - Listing OLE DB Providers
-------------------
01/01/2001 01:01:01 - ---------------------------- SQLOLEDB (Microsoft OLE DB Provider for SQL Server)
-------------------
01/01/2001 01:01:01 - ---------------------------- Microsoft.Jet.OLEDB.4.0 (Microsoft Jet 4.0 OLE DB Provider)
-------------------
01/01/2001 01:01:01 - *-- L O G I N --* (Begin)
-------------------
01/01/2001 01:01:01 - Table=ORDERS - (1 of 2)
-------------------
01/01/2001 01:01:01 - Database Connection Type=OLE DB (ADO)
-------------------
01/01/2001 01:01:01 - Provider=SQLNCLI11
-------------------
01/01/2001 01:01:01 - Set Login: Server,Path,DSN=SQLSERVER01
-------------------
01/01/2001 01:01:01 - ERROR: Connectivity to database failed... moving on...
-------------------
01/01/2001 01:01:01 - ERROR: Catastrophic error during export. Message=Error in File Daily Sales 10101_20202_{12345678-1234-1234-1234-123456789012}.rpt:
Failed to open the connection.
-------------------
The tell: the table's login block says Provider=SQLNCLI11 - that is what the report expects. But SQLNCLI11 is nowhere in the machine's provider list higher up in the log. Expected vs. installed, side by side in one log.
A customer's report ran perfectly on the workstation where it was designed in Crystal Reports, but failed on the Report Runner machine. The log file showed the report requesting the OLE DB provider SQLNCLI11 (SQL Server Native Client 11.0), and the machine's list of installed providers did not include it.
Here's the key concept: when a report is designed, Crystal Reports saves the connection type and the driver or provider it was built with, by name. At run time, a matching 32-bit driver of that same name and family must be present. It does not have to be the byte-for-byte identical build from the design machine, but installing a different SQL Server driver does not help, because the report is not asking for "any SQL Server driver" - it is asking for "SQL Server Native Client 11.0" specifically, and Windows does not substitute one provider for another.
Fix/Resolution: Install the same database drivers used on the Crystal Reports design machine onto every machine that runs the reports. In this case, installing SQL Server Native Client 11.0 (32-bit) registered the SQLNCLI11 provider, and the report ran. This is a good standing rule: any driver used to design a report should be installed on every Report Runner machine.
---
What the log file showed (failing machine) ("compressed" log highlighting key lines we look at):
01/01/2001 01:01:01 - ---------------------------- DSN: REPORTSDB, Driver: MySQL ODBC 8.0 Unicode Driver, Path: C:\Windows\SysWOW64\myodbc8w.dll, Version: 8.0.33.0
-------------------
01/01/2001 01:01:01 - *-- L O G I N --* (Begin)
-------------------
01/01/2001 01:01:01 - Table=INVENTORY - (1 of 1)
-------------------
01/01/2001 01:01:01 - Database Connection Type=ODBC (RDO)
-------------------
01/01/2001 01:01:01 - Set Login: Server,Path,DSN=REPORTSDB
-------------------
01/01/2001 01:01:01 - DSN exists
-------------------
01/01/2001 01:01:01 - ERROR: Catastrophic error during export. Message=Error in File Inventory Summary 10101_20202_{12345678-1234-1234-1234-123456789012}.rpt:
This field name is not known.
-------------------
The tell: the table's login block shows the report using the REPORTSDB DSN, and the DSN inventory line above shows which driver that DSN runs through - the 8.0 driver here, the 5.1 driver on the working machine below. Same report, same DSN name, different driver.
The same DSN line from the working machine's log:
01/01/2001 01:01:01 - ---------------------------- DSN: REPORTSDB, Driver: MySQL ODBC 5.1 Driver, Path: C:\Windows\SysWOW64\myodbc5.dll, Version: 5.1.13.0
-------------------
A customer ran the same report against the same MySQL database from two different PCs. One worked; the other failed with "This field name is not known." Comparing the log files from both machines showed only one difference: the working machine had the MySQL ODBC 5.1 driver installed, while the failing machine had the newer MySQL ODBC 8.0 driver.
In our support experience, MySQL driver-version mismatches cause more of these failures than most other databases. Different driver generations can present field names and data types to the report slightly differently, so a report validated under one driver version can fail field lookups under another, even though the database itself is unchanged.
Fix/Resolution: On the failing machine, the 5.1 driver (matching the working machine) was installed, and the newer 8.0 driver was removed. One step that is easy to get wrong: a DSN is tied to the driver it was created under, and the ODBC Administrator does not let you switch an existing DSN to a different driver. So recreate the DSN in the 32-bit ODBC Administrator under the 5.1 driver, using the same DSN name, server, database, port, and login settings the report expects (and the same ANSI or Unicode driver variant as the working machine). After that, the report ran correctly on both machines. Removing the 8.0 driver was part of this particular cleanup, but the essential step was getting the report's DSN onto the matching 5.1 driver. The lesson: a newer driver is not automatically more compatible with an older report - when one machine works and another does not, match the known-working driver version and DSN configuration.
---
What the log file showed ("compressed" log highlighting key lines we look at):
01/01/2001 01:01:01 - Listing OLE DB Providers
-------------------
01/01/2001 01:01:01 - ---------------------------- SQLOLEDB (Microsoft OLE DB Provider for SQL Server)
-------------------
01/01/2001 01:01:01 - ---------------------------- Microsoft.Jet.OLEDB.4.0 (Microsoft Jet 4.0 OLE DB Provider)
-------------------
01/01/2001 01:01:01 - *-- L O G I N --* (Begin)
-------------------
01/01/2001 01:01:01 - Table=PRODUCTS - (1 of 1)
-------------------
01/01/2001 01:01:01 - Database Connection Type=OLE DB (ADO)
-------------------
01/01/2001 01:01:01 - Provider=Microsoft.ACE.OLEDB.16.0
-------------------
01/01/2001 01:01:01 - Set Login: Server,Path,DSN=\\SERVER01\Data\Sales.mdb
-------------------
01/01/2001 01:01:01 - File/Path Exists: \\SERVER01\Data\Sales.mdb
-------------------
01/01/2001 01:01:01 - ERROR: Connectivity to database failed... moving on...
-------------------
01/01/2001 01:01:01 - ERROR: Catastrophic error during export. Message=Error in File Production Schedule 10101_20202_{12345678-1234-1234-1234-123456789012}.rpt:
Unable to connect: incorrect log on parameters.
-------------------
The tell: the table's login block asks for Provider=Microsoft.ACE.OLEDB.16.0, but the only Access-family provider in the machine's list is the old Jet 4.0. And note File/Path Exists - the database file itself is fine; the missing provider is the whole problem.
A customer set up a brand-new Windows 11 computer, installed Report Runner, and found that reports reading a Microsoft Access database (a .mdb file on the network, for example \\SERVER01\Data\Sales.mdb) would not connect. The log file showed the report requesting the Microsoft.ACE.OLEDB.16.0 provider, and that provider was missing from the machine's provider list. Nothing was wrong with the reports or the database file; the new machine simply did not have the 32-bit Access driver yet, because it does not come with Windows.
There was a complication: the machine had 64-bit Microsoft Office installed, and Microsoft's 32-bit Access Database Engine installer refuses to install next to 64-bit Office.
Fix/Resolution: Install the 32-bit Microsoft Access Database Engine 2016 Redistributable. It provides the Access, Excel, Text/CSV, and dBASE drivers in one package (dBASE support returned in the 2016 engine), and it registers both the Microsoft.ACE.OLEDB.16.0 provider and the older Microsoft.ACE.OLEDB.12.0 name, so reports built against earlier ACE installations should keep working without changes. When 64-bit Office blocks the installer, there is a common workaround - running the installer from a command prompt with the /quiet switch, which skips the installer's Office check - but be aware it is NOT guaranteed. Because /quiet hides all messages, a failed install may show no onscreen error, so verify afterward: for OLE DB connections, confirm the provider appears in the provider list near the top of a fresh Report Runner log; for ODBC connections, confirm the driver and DSN in the 32-bit ODBC Administrator. And even a successful install can be undone later by an Office update or repair, since modern Office and the 2016 driver share the same internal version (16.0). The dependable fixes keep the whole stack on one architecture: 32-bit Office alongside 32-bit Report Runner, or moving to the 64-bit edition of Report Runner together with 64-bit database drivers. In this case the customer switched to 32-bit Office, and the reports connected normally.
Note/Warning: We've had cases where nothing 32-bit would install unless the 64-bit Microsoft Office install was removed (uninstalled)
---
What the log file showed ("compressed" log highlighting key lines we look at):
01/01/2001 01:01:01 - ---------------------------- DSN: MS Access Database, Driver: Microsoft Access Driver (*.mdb, *.accdb), Path: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\ACEODBC.DLL, Version: Unknown (file may be missing or cannot be accessed)
-------------------
01/01/2001 01:01:01 - Listing OLE DB Providers
-------------------
01/01/2001 01:01:01 - ---------------------------- SQLOLEDB (Microsoft OLE DB Provider for SQL Server)
-------------------
01/01/2001 01:01:01 - ---------------------------- Microsoft.Jet.OLEDB.4.0 (Microsoft Jet 4.0 OLE DB Provider)
-------------------
01/01/2001 01:01:01 - *-- L O G I N --* (Begin)
-------------------
01/01/2001 01:01:01 - Table=CODES - (1 of 3)
-------------------
01/01/2001 01:01:01 - Database Connection Type=OLE DB (ADO)
-------------------
01/01/2001 01:01:01 - Provider=Microsoft.ACE.OLEDB.16.0
-------------------
01/01/2001 01:01:01 - Set Login: Server,Path,DSN=\\SERVER01\Data\Codes.mdb
-------------------
01/01/2001 01:01:01 - File/Path Exists: \\SERVER01\Data\Codes.mdb
-------------------
01/01/2001 01:01:01 - ERROR: Catastrophic error during export. Message=Error in File Hot List 10101_20202_{12345678-1234-1234-1234-123456789012}.rpt:
Unable to connect: incorrect log on parameters.
-------------------
The tell: three signals in one log. The table's login block still asks for Provider=Microsoft.ACE.OLEDB.16.0 and File/Path Exists confirms the database file is fine - but that provider has vanished from the provider list, and the ACE ODBC driver file's version reads "Unknown (file may be missing or cannot be accessed)". The report didn't change; the driver installation underneath it broke.
A customer had been running scheduled reports against an Access database for years without a problem. After a routine Windows update, every report using the Access connection began failing with "Unable to connect: incorrect log on parameters." The database file itself was fine, and the path to it had not changed.
The log file told the story: the machine's list of installed OLE DB providers no longer included the Microsoft.ACE.OLEDB.16.0 provider the reports use, and a separate ACE component - the ODBC driver file ACEODBC.DLL - was reported as missing or unreadable. Two different pieces of the same Access driver package broken at once points to one cause: the overall 32-bit ACE installation and its registrations had been damaged. The failure began immediately after Windows/Office servicing, and this is a known pattern: updates can quietly damage the 32-bit ACE installation.
Fix/Resolution: Reinstall the 32-bit Microsoft Access Database Engine 2016 Redistributable. The reinstall is what restores the missing files and provider registrations; rebooting afterward is good practice. In this case, after the reinstall and reboot, the log file's provider list showed the ACE provider again, and the connection errors stopped. If this happens to you, an update damaged the driver installation - the fix is putting the driver back.
---
What the log file showed ("compressed" log highlighting key lines we look at):
01/01/2001 01:01:01 - ---------------------------- DSN: SALESDB, Driver: SQL Server Native Client 11.0, Path: C:\Windows\SysWOW64\sqlncli11.dll, Version: 2011.0110.2100.60
-------------------
01/01/2001 01:01:01 - *-- L O G I N --* (Begin)
-------------------
01/01/2001 01:01:01 - Table=ORDERS - (1 of 4)
-------------------
01/01/2001 01:01:01 - Database Connection Type=ODBC (RDO)
-------------------
01/01/2001 01:01:01 - Set Login: Server,Path,DSN=SALESDB
-------------------
01/01/2001 01:01:01 - DSN exists
-------------------
01/01/2001 01:01:01 - ERROR: Connectivity to database failed... moving on...
-------------------
01/01/2001 01:01:01 - ERROR: Catastrophic error during export. Message=Error in File Weekly Orders 10101_20202_{12345678-1234-1234-1234-123456789012}.rpt:
Database Connector Error: 'SSL Provider: The client and server cannot communicate, because they do not possess a common algorithm'
-------------------
The tell: nothing is missing here - the login block finds the DSN ("DSN exists"). But "do not possess a common algorithm" is Windows saying the two sides could not agree on an encryption protocol, and the DSN inventory shows why: driver version 2011.0110.2100.60 is the original RTM build, which predates TLS 1.2 support.
A customer's IT department tightened network security by disabling older encryption protocols (requiring TLS 1.2 for all connections to their SQL Server). Afterward, reports that connected through SQL Server Native Client 11 began failing to connect.
This is the reverse of Case Study 2: here the installed driver build was too old. The SQL Server client components (together with Windows), not Report Runner, negotiate the encrypted connection. SQL Server Native Client 11 CAN speak TLS 1.2 - but only in its updated builds. The original builds cannot, so when the server started requiring TLS 1.2, the old build could no longer get in the door.
Fix/Resolution: There are two valid paths. The first is to update the existing driver: installing the updated 32-bit SQL Server Native Client 11 build (the TLS 1.2 release) keeps the exact driver and provider name the report expects, so nothing about the report or its DSN has to change. The second path, which this customer chose, is moving to a modern 32-bit SQL Server driver - and here the connection type matters. For an ODBC connection, install the modern ODBC driver (ODBC Driver 17 or 18 for SQL Server) and recreate the DSN under it. For a report saved against the SQLNCLI11 OLE DB provider, installing a new driver is not enough by itself; the connection must be pointed at the replacement provider (MSOLEDBSQL). One caveat on the newest generation: ODBC Driver 18 and OLE DB Driver 19 turn encryption ON by default (ODBC 17 and OLE DB 18 do not), so a server without a trusted certificate may also need "Trust Server Certificate" enabled in the connection - that setting bypasses certificate checking; it is not what provides TLS 1.2. If your IT department announces a TLS or encryption change, plan on checking your database driver builds at the same time.
---
What the log file showed (new server) ("compressed" log highlighting key lines we look at):
01/01/2001 01:01:01 - Warning: No DSNs found
-------------------
01/01/2001 01:01:01 - *-- L O G I N --* (Begin)
-------------------
01/01/2001 01:01:01 - Table=SHIPMENTS - (1 of 5)
-------------------
01/01/2001 01:01:01 - Database Connection Type=ODBC (RDO)
-------------------
01/01/2001 01:01:01 - Set Login: Server,Path,DSN=ERPDATA
-------------------
01/01/2001 01:01:01 - ERROR: Connectivity to database failed... moving on...
-------------------
01/01/2001 01:01:01 - ERROR: Catastrophic error during export. Message=Error in File Shipment Detail 10101_20202_{12345678-1234-1234-1234-123456789012}.rpt:
Failed to open the connection.
-------------------
The same section of the old server's log:
01/01/2001 01:01:01 - ---------------------------- DSN: ERPDATA, Driver: Progress OpenEdge 11.7 Driver, Path: C:\Progress\OpenEdge\bin\pgoe27.dll, Version: 07.16.0175 (B0296, U0197)
-------------------
01/01/2001 01:01:01 - ---------------------------- DSN: MS Access Database, Driver: Microsoft Access Driver (*.mdb, *.accdb), Path: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\ACEODBC.DLL, Version: 16.0.5338.1000
-------------------
01/01/2001 01:01:01 - ---------------------------- DSN: SALESDB, Driver: SQL Server Native Client 10.0, Path: C:\Windows\SysWOW64\sqlncli10.dll, Version: 2009.0100.4042.00
-------------------
The tell: the table's login block asks for the ERPDATA DSN, but the new server's log says "No DSNs found" - while the old server's log lists the full driver inventory the reports were built on. Comparing the two logs is the whole diagnosis.
A customer migrated Report Runner Batch from an old server to a new one. The software installed fine and the scheduled jobs were copied over, but various reports failed on the new server even though they still ran on the old one. Different reports failed with different connection errors, which was the clue: this was not one broken report, it was an environment difference.
The old server had accumulated years of database drivers: the Access/Excel (ACE) drivers, two generations of SQL Server drivers, and a specialty ERP driver. The new server had almost none of them. Every report that depended on a driver the new server lacked failed.
Fix/Resolution: Install the same database drivers - same versions where possible - on the new server that existed on the old one. The Report Runner log file makes this easy: near the top of every log, Report Runner prints an inventory of the machine's DSNs, drivers (with version numbers), and OLE DB providers. Compare the old server's log to the new server's log, and the missing drivers stand out immediately. Install what is missing, and the reports come back. Two details deserve special attention on the new server: recreate DSNs as System DSNs (a User DSN belongs to one Windows profile and may be invisible to scheduled jobs), and test at least one report while running under the same Windows account that runs Report Runner Batch - a DSN or mapped path that works for the logged-in administrator may not exist for the scheduled process. Match each driver's bitness and ANSI/Unicode variant exactly as they were on the old server. When planning any server migration, treat the driver inventory as part of the checklist, right alongside the software install and the scheduled jobs.
---
If any of these situations look familiar and the driver you need is no longer available from the vendor, contact us - we maintain an archive of original 32-bit driver installers for exactly these compatibility cases.