Jiwa

So some time yesterday, the customer's system stopped printing.

A bit of digging got me an "Encryption not supported" error, which led me to discover that SQL Native Client 11.0 is deprecated and technically not supported for SQL 2019.
According to https://docs.microsoft.com/en-us/sql/re ... rver-ver15, only up to SQL 2014 is supported. The current recommended client is the new ODBC client.

Anyways, it has been working for a few months, so some helpful Windows update must have broken it (There were a number applied to the remote desktop server yesterday).

Thankfully, y'all had a similar problem previously (if in reverse, I think) https://docs.jiwa.com.au/display/J7UG/C ... gon+Failed.

The solution for my problem is the same: make Crystal use the OLEDB driver instead.

This is the bit of magic code, adapted for 7.2.1 (using Plugin.Manager instead of Manager.Instance). I just put the one line into an existing 'general-purpose' plugin that the customer has.

Code: Select all

public class ApplicationManagerPlugin : System.MarshalByRefObject, JiwaFinancials.Jiwa.JiwaApplication.IJiwaApplicationManagerPlugin
{

    public override object InitializeLifetimeService()
    {
        // returning null here will prevent the lease manager
        // from deleting the Object.
        return null;
    }

    public void Setup(JiwaFinancials.Jiwa.JiwaApplication.Plugin.Plugin Plugin)
    {
      Plugin.Manager.CrystalReportsProviderName = "SQLOLEDB";
    }
}

That docs page had 2 plugins - one for 7.00.175 and one for 7.01.00 or later - it looks like you took the 7.00.175 one and modified it to be identical to the 07.01.00 one!

Glad you got it sorted, anyway. I'll log an issue to make SQLOLEDB the default - without the need for a plugin.

DEV-9182 for 7.2.7
DEV-9183 for 7.2.1 SR10

Mike.Sheen wrote:That docs page had 2 plugins - one for 7.00.175 and one for 7.01.00 or later - it looks like you took the 7.00.175 one and modified it to be identical to the 07.01.00 one!

doh!

research under pressure...

pricerc wrote:

Mike.Sheen wrote:That docs page had 2 plugins - one for 7.00.175 and one for 7.01.00 or later - it looks like you took the 7.00.175 one and modified it to be identical to the 07.01.00 one!

doh!

research under pressure...

in my defense, perhaps you could update the page to say 7.1 and later ?

pricerc wrote:in my defense, perhaps you could update the page to say 7.1 and later ?

Fair point.... done.

Mike.Sheen wrote:

pricerc wrote:in my defense, perhaps you could update the page to say 7.1 and later ?

Fair point.... done.

Thanks. It'll help the next person TL;DR'ing the page.

Also the presence of a 7.0, and a 7.1 when 7.2 is current might cause a passer-by to assume that the issue doesn't exist in 7.2.

What a confusing mess they made of this.

So, SQLOLEDB was being deprecated years ago so they were pushing people using Managed .NET apps to use SQLNCLI* for a while.

But then in 2018 they undeprecated SQLOLEDB and that was the new old provider to use - HOWEVER they also changed the provider name to MSOLEDBSQL.

https://docs.microsoft.com/en-us/archiv ... sql-server

I'm about to test, this - but we're going to use MSOLEDBSQL as the default provider for reports, and rely on a plugin to change that to whatever else is desired.

Mike.Sheen wrote:What a confusing mess they made of this.

So, SQLOLEDB was being deprecated years ago so they were pushing people using Managed .NET apps to use SQLNCLI* for a while.

But then in 2018 they undeprecated SQLOLEDB and that was the new old provider to use - HOWEVER they also changed the provider name to MSOLEDBSQL.

https://docs.microsoft.com/en-us/archiv ... sql-server

I'm about to test, this - but we're going to use MSOLEDBSQL as the default provider for reports, and rely on a plugin to change that to whatever else is desired.

They're a special bunch over there at Microsoft.

Edit to add: I think it's the TLS 1.2 that broke over the weekend.