The quickest way to resolve this is likely by contacting your First Line of Support (FLOS), but there is something that might be worth checking first.
I'll briefly describe this check, then I'll give a more detailed explanation below.
Take a look at the connection string that's being used in your scripts:
Does it include an Encrypt attribute, as in the above example?
If so, then if the Encrypt attribute value is optional (as above), try changing it to false.
And if the Encrypt attribute value is mandatory, try changing it to true.
After making any changes to the connection string, restart the Application Server so OnBase picks up the changes (that should happen automatically when you save the changes in web.config).
If there is no Encrypt attribute, or there is one but its value is already true or false, or you make the change and it makes no difference, then I recommend contacting your FLOS for further troubleshooting
Detailed explanation:
If checking/modifying the connection string's Encrypt attribute as described above worked, here's the explanation:
If your OnBase database is Sql Server, OnBase communicates with it using ADO.NET. (Apart from the OnBase Thick Client, which uses a different protocol, ODBC).
The ADO.NET communication uses Microsoft's .NET libraries. Prior to OnBase 24.1 we used the System.Data.SQLClient library. But then in OnBase 24.1, following Microsoft's guidance, we changed to a more modern library, Microsoft.Data.SQLClient.
(This article explains why Microsoft recommended moving from System.Data.SQLClient to Microsoft.Data.SQLClient: https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/)
As far as the existing database functionality is concerned there's no difference: Microsoft.Data.SQLClient is backwards-compatible with System.Data.SQLClient.
However, the connection strings are not totally compatible. There's a difference in the way System.Data.SQLClient and Microsoft.Data.SQLClient treat encryption of the database connection.
Microsoft.Data.SQLClient defaults to encrypting the database connection, so if there's no Encrypt attribute in the connection string, the database connection is encrypted. Previously, with Microsoft.Data.SQLClient , the default is an unencrypted connection; to specify an encrypted connection, you have to include an explicit Encrypt=true in the connection string.
To use an encrypted connection, you need to set up the appropriate certificates: https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/certificate-requirements?vie...
If you don't want, or haven't configured, SQL Server for encryption then if you're using Microsoft.Data.SQLClient you have to explicitly set Encrypt=optional in the connection string.
OnBase 24.1 internally uses Microsoft.Data.SQLClient . But it's possible there are Unity Scripts that still use the older library System.Data.SQLClient . The binaries for both are included with OnBase, but if they're both using the same connection string, you have to ensure that the values are compatible.
This means that any Encrypt attribute value must be compatible with both. Microsoft.Data.SQLClient accepts values of mandatory/optional/strict, but also accepts true as a synonym for mandatory, and false as a synonym for optional. If omitted, the default is mandatory.
System.Data.SQLClient accepts values of true/false; if omitted, the default is false.
So if you want to allow Microsoft.Data.SQLClient and System.Data.SQLClient connection to use the same connection string, you need to explicitly include an Encrypt=true or Encrypt=false attribute, depending on whether the database connection is encrypted or not.
To return to this specific situation where connections in Unity Scripts are failing. My guess is that the scripts may be using System.Data.SQLClient but the OnBase connection strings have been updated to include incompatible values (e.g. optional) for the connection string Encrypt attribute. Hence my advice to check, and for compatibility change the Encrypt values to true or false.
