John Lyons said:

I've followed the 64bit workaround... 
"HKLM\SOFTWARE\WOW6432Node\Sage\Line 50\SettingsFolder" /d C:\ProgramData\Sage\Accounts\2023

That returns "The system cannot find the path specified"

I'm assuming you got that from this article https://gb-kb.sage.com/portal/app/portlets/results/viewsolution.jsp?solutionid=200427112231214&view=print but it looks like that article is incorrect and is should have "reg add " at the start of that, so it looks like you have already got to the correct command. However the path would be incorrect for v32 and you would need to use C:\ProgramData\Sage\Accounts\2026 instead.

John Lyons said:

Sdata service works and dropping localhost:5495/.../ into a web browser confirms the port works and is returning XML data allbeit with object error.
Unable to locate the specified object 'accounts50/GCRM/-'

That would be correct as it's not a valid Sdata Uri because you aren't specifying the resource kind. Try something like accounts50/GCRM/-/taxCodes and you should see something returned by that.

Hope that helps

Thanks so much for the reply!

I've got one company in the 2026 path so I've updated the path and am testing against that now. (The other companies although V32 are in 2023 and 2025 - not sure if that's relevant or odd for the future - and wondering now if a removal and fresh install of V32 may be the way to go)

Sage is reporting SData as enabled in Help>About but still no entry in Tools>Internet Options.

Given the service is running and part of the URL is known, does having the tab visible in Sage to pull the URL still relevant? ie can I build the rest of the URL from knowing the Data directory or RDA ID/Dataset ID?

The only reason I need this is to get the URL for the CData ODBC read/write driver working but wondering whether I may as well code python directly to SData?

John Lyons said:

I've got one company in the 2026 path so I've updated the path and am testing against that now. (The other companies although V32 are in 2023 and 2025 - not sure if that's relevant or odd for the future - and wondering now if a removal and fresh install of V32 may be the way to go)

A fresh install won't change things. Sdata will only detect datasets for a single version, but the datasets themselves do not need to be the same version if that makes sense.

John Lyons said:

Sage is reporting SData as enabled in Help>About but still no entry in Tools>Internet Options.

Apologies, I forgot to say this in my original reply but that is expected if you are running the 64 bit version of Accounts. The thing you see in Tools -> Internet Options is a plugin. Sdata was only ever developed as 32 bit and has not been changed to support 64 bit. This means the 64 bit version of Accounts cannot load the Sdata plugin as it is still 32 bit so you'll not see anything in Accounts. Help -> About does not use a plugin model and simply detects if the service and adapter are deployed.

If you really wanted the plugin to show you could uninstall the 64 bit version of Accounts and install the 32 bit version, but that would affect other integrations from Accounts such as Send to Excel, Mail Merge, etc.

John Lyons said:

Given the service is running and part of the URL is known, does having the tab visible in Sage to pull the URL still relevant? ie can I build the rest of the URL from knowing the Data directory or RDA ID/Dataset ID?

You cannot determine the dataset Id from the location on disk but you can get it fairly easily by looking at the Sdata registry on the PC (see this link for details  https://sage.github.io/SData-2.0/pages/core/1401/ )

John Lyons said:

The only reason I need this is to get the URL for the CData ODBC read/write driver working but wondering whether I may as well code python directly to SData?

Yes, if all you need is the dataset Uri then the simplest thing would be to look at the registry endpoint in a web browser. If you are comfortable writing code then you can of course use that to query that same endpoint if you find that easier. To be honest that is all the plug that you cannot load is doing anyway.

Hope that helps

Got as far as http://localhost:5495/sdata/accounts50/GCRM/-/$schema asking for a username and password but none of the manager or username combos work that we'd usually use.

Not been able to find anything in the registry directly relating to registered endpoints so even more stuck than I was before.

If I can at least confirm I'm calling the right address with auth details and the right ID's for the companies I can flip to python/PHP/Curl to figure the rest out.

John Lyons said:

Got as far as localhost:5495/.../$schema asking for a username and password but none of the manager or username combos work that we'd usually use.

That suggests that the Sdata adapter is correctly registered and is picking up data from somewhere. The username and password issue could be legitimate and the credentials provided are be incorrect for the data you are connecting to. Or  it is possible there is some problem with the data and the authentication fails because the connection to the data fails. It is also possible (but far less common) that something is interfering with connecting to the data e.d. permissions issues, Ant-virus, etc. All just conjecture though.

John Lyons said:

Not been able to find anything in the registry directly relating to registered endpoints so even more stuck than I was before.

To be clear I am referring to the Sdata registry endpoint (see link in above reply) and not the Windows registry. If you are getting a response from http://localhost:5495/sdata/accounts50/GCRM/-/$schema then there must be something registered with Sdata and the registry endpoint should shoe the 50 Accounts application, GCRM schema and at least one dataset

John Lyons said:

If I can at least confirm I'm calling the right address with auth details and the right ID's for the companies I can flip to python/PHP/Curl to figure the rest out.

You are calling the right address, although as a general rule I would not recommend using the default dataset identifier (the dash) as it is possible for this to change over time

Yup, I think the default dataset ID is causing the issue with authentication.
Is there any way of getting the correct ID to use for the path from within Sage?  I've tried the RDA dataset ID but that just returns a not found error.

The default dataset identifier shouldn't cause any authentication issues as such, but the actual dataset it connects to is not easily predictable (one of the big reasons I recommend not using it).

RDA is a separate thing to Sdata so the Id is not related and this is why it doesn't work. The actual Id is not shown anywhere in the UI except in the plugin that you are unable to run. However that plugin is simply querying the Sdata registry endpoint so you can call it programmatically, use curl, etc, or even simply open it in a web browser. The response is XML but will contain the datasets along with the company name Uri for each one.