New answers tagged

3

The context of this question is strikingly similar to this question: LOB_DATA, slow table scans, and some I/O questions. But the direction is a bit different. In order to answer whether or not there would be much benefit in moving the XML column into its own table requires answering the following questions first (and I will explain why in a moment): How ...


3

The database engine is pretty smart about this and does not read LOB pages unless it has to as far as I can tell, but I created a test-rig to double-check. Test Rig USE master GO SET NOCOUNT ON GO CREATE DATABASE bigXMLTest GO ALTER DATABASE bigXMLTest SET RECOVERY SIMPLE GO ALTER DATABASE bigXMLTest MODIFY FILE ( NAME = N'bigXMLTest', SIZE = 20GB , ...


0

One of the easiest ways to create an XSD is open the XML (not XSD) file in Visual Studio or SQL Server Management Studio (SSMS) and click the 'XML' menu then 'Create Schema ...': I think this will be easier for you than using SSIS. Create some XML which looks how you want, and create the XSD from that. Make sense?


6

You could do that using the sql:column function and a Common Table Expression (CTE), something like this: CREATE TABLE #tmp ( col2 XML ) INSERT INTO #tmp ( col2 ) VALUES ( '<Root> <Row> <Rowid>trim this value </Rowid> </Row> </Root>' ) SELECT 'before' s, * FROM #tmp ;WITH cte AS ( SELECT col2, RTRIM(...


3

If I understand the Question correctly, you need to use the XML_SCHEMA_NAMESPACE built-in function to extract the Schema Collection, and you can find the list of those in the sys.xml_schema_collections system catalog view. You can use something along the lines of: SELECT CONVERT(NVARCHAR(MAX), XML_SCHEMA_NAMESPACE(sch.[name], xsc.[name])) AS [XSD] FROM ...



Top 50 recent answers are included