This is the test VBS script:-

Set oSDO = CreateObject("SDOEngine.28")

' Create the Workspace
Set oWS = oSDO.Workspaces.Add("Example")

strDataPath = "C:\ProgramData\Sage\Accounts\2022\DemoData\ACCDATA\"
cSDO_Username = "MANAGER"
cSDO_Password = ""

' Connect to Data Files
oWS.Connect strDataPath, cSDO_Username, cSDO_Password, "Example"

Set oSetupRecord = oWS.CreateObject("SetupData")

oSetupRecord.Read 1

cCompanyName = oSetupRecord.Fields("NAME").Value

MsgBox cCompanyName

' Disconnect & Destroy Objects
oWS.Disconnect
Set oSDO = Nothing
Set oWS = Nothing

Hi.

Is there a certificate with the name "sage.grpc.root" under the certificate store "Certificates - Local Computer\Trusted Root Certification Authorities\Certificates"? I imagine there will be given that Sage 50 desktop is working fine, but worth double checking.

Is it possible to also check that the PC system time is not out of sync please?

When the issue occurs, does restarting the Sage 50 data service resolve it?

Thanks.

Hi

Thanks for your reply.

Yes, that root certificate is present.

The PC time is in sync with a time server and the current time is correct.

No, the issue isn't resolved by restarting the Sage 50 data service.  Nor is it resolved by restarting Windows.

Best regards

Keith

Thanks for the info Keith. What kind of PC environment is the script failing in? Is it Windows 10?

Given that Sage 50 desktop works as expected but the VBS does not, one thing I'm wondering is if the VBS needs to set the SecurityProtocolType in case the environment is using an incompatible one. The Sage 50 Desktop sets it using C# as follows. Not too familiar with VBS but hopefully the code is easy to translate:

int securityprotocol = (int)ServicePointManager.SecurityProtocol;

securityprotocol &= ~(int)SecurityProtocolType.Ssl3;
securityprotocol &= ~(int)SecurityProtocolType.Tls;
securityprotocol |= (int)SecurityProtocolType.Tls11;
securityprotocol |= (int)SecurityProtocolType.Tls12;

ServicePointManager.SecurityProtocol = (SecurityProtocolType)securityprotocol;

The failing environments are all Windows 10.  The one working environment we have is Windows 11, but that is likely to be purely coincidental.  I don't believe updating to Windows 11 will be the answer, to be honest.

I don't know anything about SecurityProtocolType and it's never featured in our code or any code examples published by Sage.  I wouldn't know where to introduce it and I definitely can't work out C# translation.

In all cases, the problems only started after updating from v27 to v28.  Prior to that all cases had functioning SDO.

Thanks Keith.

No I wouldn't suggest updating to Windows 11 is the answer, but the description indicates an environment issue that may require configuration on the SDO app.

SecurityProtocolType is normally set in your startup code (e.g., Main) and ensures your app uses a protocol compatible with the server if the environment default is not compatible.

In v28 we rely on SSL certificates to communicate with the Sage 50 service as part of new security improvements.

I'm trying to set up a VBS with the same code as yours and test locally. I'll see if I can translate the C# code in VBS and provide you with an example (just trying to familiarise myself with VBS).

Thanks.

OK, thanks Ali. I understand a bit more now.

However, surely if Sage SDO needs the same configuration as the Sage desktop application requires, shouldn't it also be setting this security protocol so that it doesn't fail when talking to the Sage 50 service?

I have no problem adding to our VBS scripts if required, but I'd expect this problem could manifest itself quite frequently with other SDO based applications.

Best regards

Keith

Hi Keith. If the issue turns out to be related to setting SecurityProtocolType then yes we can update SDO to cater for that. I'm hoping to investigate further today to confirm if it's related to setting SecurityProtocolType.

Have you got the build number of your Windows 10 PC where the script fails please, just so that I can test in a similar environment.

Thanks.

These are the details of one of the PCs we have where the script fails:-

Device Specs:

Device name SUPPORT07

Full device name SUPPORT07.synergist.local

Processor Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz   3.19 GHz

Installed RAM 8.00 GB

Device ID 1BF1C8FF-4460-4F59-9F14-34244466955F

Product ID 00330-50288-88368-AAOEM

System type 64-bit operating system, x64-based processor

Pen and touch No pen or touch input is available for this display

Windows Specs:

Edition Windows 10 Pro

Version 21H2

Installed on ‎24/‎08/‎2020

OS build 19044.1469

Experience Windows Feature Experience Pack 120.2212.3920.0

Many thanks for the info Keith. I'll see what I can find. Will keep you updated.

Thanks.