Not sure if this is a Postman issue but would like some help ruling it out.
So, I am storing data into an MS SQL Server 2008 database using a SQLXML updategram.
SQLXML provides a RESTful-like XML interface to SQL server.
For my test purposes, I have a table ‘PILongTextTest’ with the following structure
[PIUID] [int] NOT NULL,
[LocationLong] nvarchar NULL,
[DateCreated] [smalldatetime] NOT NULL,
[LocID] [int] IDENTITY(1,1) NOT NULL
I have an updategram with the following structure
<intros xmlns:updg=“urn:schemas-microsoft-com:xml-updategram” xmlns:sql=“urn:schemas-microsoft-com:xml-sql”>
SELECT 1 as Tag,
NULL as parent,
PIUID as [PILongTextTest!1!PIUID],
LocationLong as [PILongTextTest!1!LocationLong!xml],
DateCreated as [PILongTextTest!1!DateCreated],
LocID as [PILongTextTest!1!LLocID]
WHERE PIUID = @piuid
FOR XML Explicit
The updategram is accessed using this URI in Postman
A depth of 3.0 m.
I would expect this to create a database record, and return an xml copy of that record, which it does
If I change the data to add a non-breaking space, the data seems to be stored correctly, but when return to Postman, is not displaying ‘correctly’. There is an ‘odd’ Â character in front of the space
I believe this is a marker in the character encoding to indicate the use of UTF-8.
I have tested Postman similarly with other extended characters with similar results.
I believe my use of nvarchar in the table definition means that the table is capable of storing UTF-8 correctly.
So my questions are:
- Is that data being stored correctly in the database, and how can I test this? (perhaps outside the scope of this forum)
- On the assumption that it is stored correctly, is Postman displaying these ‘extended’ characters as expected? (SQL Server Management Studio displays similarly)
- Is there a way I can change this behaviour, perhaps in the http header (this IS Postman relevant) and requests?