Cannot perform a fetch fields action

WEB TMS WEB Core
1
I created a XDATA server that generates the follow:
[ { "Hours Worked": 11.5, "Local Department": "b: Development", "Local Department shortcut": "D-GM", "PEV": "Teamsit", "State": "Not Started", "WorkEntryMonth": 2, "WorkEntryYear": 2018 }, { "Hours Worked": 6.5, "Local Department": "b: Development", "Local Department shortcut": "D-GM", "PEV": "Teamsit", "State": "Not Started", "WorkEntryMonth": 2, "WorkEntryYear": 2018 }]
OK there are some more records, but this is not a problem, I think.

I generated a vcl client app with a dataset and the three components
WebClientConnection1
WebClientDataset1
WebDataSource1

They are linked accordingly to each other and the connectio has been set up to get the data from the server.

When at designtime everything is set to active I should be perform a "fetch fields" action from the WebClientDataset1 but instead nothing happens.

I have to add that, on the XDATA server, I generate the DataStream through a third party component and not from some Firedac component as FDBatchMoveJSONWriter1 and FDBatchMove. If I do that then I can fetch the fields on the client side. 

So I think it is a problem on the server side. The strange thing is that the two Json files look very similar and compatible, so that I thought it should work fine. 

Where can I look for the specification of WebClientDataSet about the Json format to use? Could be Unicode?

Or do you have some idea to solve the problem?
I use Delphi 10.3 Version 26.0.33219.4899 and TMS Web Core 1.2.3.1 and XDATA 4.5.0.0.

Many thanks in advance,
Francesco
2
I followed your beautiful tutorial "TMS XData: Accessing any database with SQL queries via the TMS XData RESTserver".
Nevertheless I had to change a lot because I do not have FireDac that can access to MSSQL (which is what I need). So at first I used SQLite and it worked well. Then I had to get rid of all the Firedac staff and generate a TStream, better a TMemorystream, containing the data of a Dataset (I use UNIDAC) in Json format. To do that I used a component from Scalabium (SMExport component suite- Mike Shkolnik) to generate that Stream. It works well, also quite fast if you disable the user feedback on transforming the data.
The result from the browser was well promising, but the WebClientDataset did not want to play with.

Now I changed the codepage of the resulting streams from unicode to ANSI_WINDOWS and everything works fine. Please mention it somewhere in your next tutorials. Where can I look at which kind of coding the Json is and which kind of coding does WebClientDataset expects.

Thanks to the flexibility of the XDATA and WEBCore products I can now solve all my immediate problems with a minimum of effort. The best way would have been to use Aurelius, but I am not in such a lucky situation. The data I have to use is imported from a cloud system that offers no API. The only way to get the data is over some reports (EXCEL files) that has to be imported in MSSQL to generate some KPIs through Views and Stored Procedures. I don' t want to write the existing queries once more in Linq, I just want to access these views and procedures and functions to get the KPI on a WEB page on the intranet.So I cannot use Aurelius directly, I do not want to generate the classes per hand. This is now a nice and fast way to get the data from a rest server connected to MSSQL to a intranet page generated through WEBCore. Many thanks!
3

Hi Francesco,


I'm glad you solved your issue, and also glad you seem to be enjoying TMS XData and TMS Web Core.
I believe you had a problem with content-type. By default the content-type of a XData service operation response is application/json, which implies encoding is UTF-8. XData handles it for you transparently if you are returning high-level types, but since you are using a raw stream, it would be up to you to guarantee that the response would have bytes representing a JSON value using UTF-8 encoding.

That's probably what you partially achieved changing it to ANSI_WINDOWS (which is UTF-8 compatible for the common characters). To save problems in future, I suggest you use UTF-8 instead of ANSI.
Alternatively, you could change the content-type of the response and set the charset to unicode. But for higher compatibility it's better to keep it UTF-8 as that's what most clients expect and understand.