System.IO.FileNotFoundException: System.Data.Odbc 4.0.0.0 not found – DatabaseProcessQueryStep - Robotiq

Answered

Hi everyone,

I have this error:

Error ocurred in step [“DatabaseProcessQueryStep”, “Insert into Log File nema uopće narudži”,”bf5ea91b-6e8a-8861-5d4b-b4c5c0800c5d”]. Error: System.IO.FileNotFoundException: Could not load file or assembly ‘System.Data.Odbc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’. The system cannot find the file specified. File name: ‘System.Data.Odbc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ at Robotiq.ScriptExecutor.Repositories.DatabaseRepository.ExecuteProcessDatabaseQuery(String connectionString, String sqlQuery) at Robotiq.ScriptExecutor.StepHandlers.Implementation.DatabaseProcessQueryHandler.HandleCore(Boolean startRobotLocaly) at Robotiq.Steps.Common.StepHandler.Handle(Boolean startRobotLocally).

The step previously used an OLE DB connection string to read an Excel file and write data to a log table.
Does anyone know why the System.Data.Odbc assembly is suddenly missing and how we can fix this?

Thanks in advance!

Process Development database read query step #excel oledb driver datatable System.Data.Odbc

Emb asked 5 days ago

You must login to post comments

Answers (1)

Best Answer

Hi Emb,

We updated our RPA platform to the latest release (built on .NET 9). In .NET 9 Microsoft retired several legacy data-access libraries, including System.Data.OleDb.
Your DatabaseProcessQueryStep still tries to load that provider (indirectly via ODBC), which is no longer present in the new runtime, so the assembly lookup fails and throws the FileNotFoundException.

Solution

Replace the OLE DB/ODBC step
- Use “Excel To Data Table Step” to import the workbook directly.
- Query the resulting DataTable with “Select From Data Table Variable Step” instead of running SQL over OLE DB/ODBC.

Because no external OLE DB/ODBC provider is required, the workflow becomes compatible with .NET 9 and future runtimes.

We do not provide troubleshooting for third-party database drivers or custom code outside the built-in step set. Migrating to native steps keeps you within the supported feature set and avoids similar breakages when the underlying .NET version changes again.

After switching to the two native Excel/DataTable steps, the workflow runs without errors on .NET 9.