Best solution: SQLXML, XML Data Binding, or MSXML?

I need some help to determine what the best solution would be for the
following scenarios where the dataset is large and performance is key:
Scenario #1
I am trying to retrieve relational data in XML from a SQL Server 2000 stored
proc. My client is a VBA Access application. I want to be able to map the xml
elements to db tables/columns and use a stored proc to collect the data and
build the xml. Validate it against the xsd. I am assuming that with large
datasets it would be faster to create the xml on the server than on the
client - desktop pcs - since I would have to loop through data rows to
create the xml using MSXML on the client, thoughts. What about annotated
schemas. Do you have to use along with XPath queries even if your result is
already filtered in an SQL sproc.
Scenario #2
I have a .Net webservice that will be the recepient of this xml and validate
it and persisit it to SQL 2K. After looking at all available options it seems
to me that using XML Data Binding & creating .Net classes based on the xsd &
loading this .Net object from xml is the cleanest solution. Reading into
SQLXML, it seems as though every method to persist data to SQL Server uses
the COM-based SQLXMLOLEDB provider and my code will have to jump from CLR to
COM. Cant see how that is good. And MSXML is also COM based parser.
Thoughts?
Scenario #1: I would look at the FOR XML functionality of SQL Server 2000 if
you want to do it in the database. Annotated schemas do not work with stored
procs. You can look into the client-side FOR XML of SQLXML 3.0 if you want
to run FOR XML over the result of a stored proc.
Re Scenario #2: The SQLXML Bulkload object can be called through the managed
providers (in the latest SP of SQLXML 3.0). You will go through COM interop,
which you don't have to for the data binding. But I think the loading may
still be faster due to the bulkload mechanism. I would suggest doing some
perf tests for your specific data...
Best regards
Michael
"Aazihh" <nowayjose@.newsgroupms.com> wrote in message
news:D56903DB-3984-4EE4-9CE1-5E1CCC9FBEA6@.microsoft.com...
>I need some help to determine what the best solution would be for the
> following scenarios where the dataset is large and performance is key:
> Scenario #1
> I am trying to retrieve relational data in XML from a SQL Server 2000
> stored
> proc. My client is a VBA Access application. I want to be able to map the
> xml
> elements to db tables/columns and use a stored proc to collect the data
> and
> build the xml. Validate it against the xsd. I am assuming that with large
> datasets it would be faster to create the xml on the server than on the
> client - desktop pcs - since I would have to loop through data rows to
> create the xml using MSXML on the client, thoughts. What about annotated
> schemas. Do you have to use along with XPath queries even if your result
> is
> already filtered in an SQL sproc.
> Scenario #2
> I have a .Net webservice that will be the recepient of this xml and
> validate
> it and persisit it to SQL 2K. After looking at all available options it
> seems
> to me that using XML Data Binding & creating .Net classes based on the xsd
> &
> loading this .Net object from xml is the cleanest solution. Reading into
> SQLXML, it seems as though every method to persist data to SQL Server uses
> the COM-based SQLXMLOLEDB provider and my code will have to jump from CLR
> to
> COM. Cant see how that is good. And MSXML is also COM based parser.
> Thoughts?

Best solution: SQLXML, XML Data Binding, or MSXML?

I need some help to determine what the best solution would be for the
following scenarios where the dataset is large and performance is key:
Scenario #1
I am trying to retrieve relational data in XML from a SQL Server 2000 stored
proc. My client is a VBA Access application. I want to be able to map the xm
l
elements to db tables/columns and use a stored proc to collect the data and
build the xml. Validate it against the xsd. I am assuming that with large
datasets it would be faster to create the xml on the server than on the
client - desktop pcs - since I would have to loop through data rows to
create the xml using MSXML on the client, thoughts. What about annotated
schemas. Do you have to use along with XPath queries even if your result is
already filtered in an SQL sproc.
Scenario #2
I have a .Net webservice that will be the recepient of this xml and validate
it and persisit it to SQL 2K. After looking at all available options it seem
s
to me that using XML Data Binding & creating .Net classes based on the xsd &
loading this .Net object from xml is the cleanest solution. Reading into
SQLXML, it seems as though every method to persist data to SQL Server uses
the COM-based SQLXMLOLEDB provider and my code will have to jump from CLR to
COM. Cant see how that is good. And MSXML is also COM based parser.
Thoughts?Scenario #1: I would look at the FOR XML functionality of SQL Server 2000 if
you want to do it in the database. Annotated schemas do not work with stored
procs. You can look into the client-side FOR XML of SQLXML 3.0 if you want
to run FOR XML over the result of a stored proc.
Re Scenario #2: The SQLXML Bulkload object can be called through the managed
providers (in the latest SP of SQLXML 3.0). You will go through COM interop,
which you don't have to for the data binding. But I think the loading may
still be faster due to the bulkload mechanism. I would suggest doing some
perf tests for your specific data...
Best regards
Michael
"Aazihh" <nowayjose@.newsgroupms.com> wrote in message
news:D56903DB-3984-4EE4-9CE1-5E1CCC9FBEA6@.microsoft.com...
>I need some help to determine what the best solution would be for the
> following scenarios where the dataset is large and performance is key:
> Scenario #1
> I am trying to retrieve relational data in XML from a SQL Server 2000
> stored
> proc. My client is a VBA Access application. I want to be able to map the
> xml
> elements to db tables/columns and use a stored proc to collect the data
> and
> build the xml. Validate it against the xsd. I am assuming that with large
> datasets it would be faster to create the xml on the server than on the
> client - desktop pcs - since I would have to loop through data rows to
> create the xml using MSXML on the client, thoughts. What about annotated
> schemas. Do you have to use along with XPath queries even if your result
> is
> already filtered in an SQL sproc.
> Scenario #2
> I have a .Net webservice that will be the recepient of this xml and
> validate
> it and persisit it to SQL 2K. After looking at all available options it
> seems
> to me that using XML Data Binding & creating .Net classes based on the xsd
> &
> loading this .Net object from xml is the cleanest solution. Reading into
> SQLXML, it seems as though every method to persist data to SQL Server uses
> the COM-based SQLXMLOLEDB provider and my code will have to jump from CLR
> to
> COM. Cant see how that is good. And MSXML is also COM based parser.
> Thoughts?

Best practise to import XML into SQL Server 2005

As title, what's the best practise of importing XML data into SQL Server 2005?

I have found this one. http://support.microsoft.com/default.aspx/kb/316005. Is it good enough?

The XML is generated by another system on daily basis. So, the import should be able to handle insert and update cases. How can I do that? Thanks!

XML Bulk load deals with loading up the data initially into SQL server. To update/delete, try this http://msdn2.microsoft.com/en-us/library/aa258671(SQL.80).aspx.

Note that SQL2005 supports xml data type natively, meaning that you can store the whole xml doc in a sql table column w/o breaking it up and saving it as a table. Keep in mind that you have that option as well depending on your specific use scenarios.

|||I have read something about the updategram. However, the information is quite piece by piece. Is there any example showing how it's working in real situation?

Best practices - currency elements

Hello! I'm a long-time SQLServer developer, but new to XML.

I find myself doing some XML related to EDI messages.

When you have a field containing a dollar amount, what format should you use in the XSD?

We've been using decimal.

But that's just half the question!

When the XML comes in and there is a round dollar amount, we've been getting the data in integer format, a five dollar order just looks like <mytotal>5</mytotal>.

Wouldn't it seem like a best practice to make this <mytotal>5.00</mytotal>?

Thanks.

Josh

Could this be a problem with the specification of the database column? For example:

Code Snippet

declare @.testo table(myTotal decimal , dec_9_2 decimal(9,2))
insert into @.testo select 5, 3
--select myTotal from @.testo

select myTotal
from @.testo
for xml path('')

/*
XML_F52E2B61-18A1-11d1-B105-00805F49916B
--
<myTotal>5</myTotal>
*/

select dec_9_2
from @.testo
for xml path('')

/*
XML_F52E2B61-18A1-11d1-B105-00805F49916B
--
<dec_9_2>3.00</dec_9_2>
*/

In the first query the source column is simply defined as a DECIMAL column and is displayed without any fractional "decimal" portion. When this column is converted to XML it displays only the whole number portion because really, the data consists of whole number only.

In the second query the source column is defined as DECIMAL (9, 2) column. This provides for 7 whole number digits and 2 decimal digits. When this column is converted to XML it displays the desired decimal places.

Can you provide the DDL for your source column?

|||

The XML is prepared by an outside source, in fact it comes from an EDI message.

I'm wondering whether - more like just how - to raise it with them as an improvement they should make.

Thanks.

Josh

|||

What I would wander is first, are ANY of these fields coming in with decimals. If none, I would definitely raise the issue if your are supposed to be getting 2-decimal accuracy. They may have an error that they are not aware of.

Also, the advantage of getting the decimals is that it eliminates doubt -- which is exactly what you are expressing. It is probably a good idea just to ask the question so that the doubt is eliminated. Much better to talk now than miss something.

sql

Best Practice for Structuring XML?

I've created a large XML document from a relational database (using AUTO,
EXPLICIT, etc.) with many elements, attributes, and subelements but now
wonder if there is a "best practice" for designing the structure for going
the other way, XML -> relational. Since I have not yet worked on the data
extraction side, maybe what I've put together makes data extraction awkward
(requiring many lines of T-SQL vs. one or two). But I definitely cannot
stomach the 'all attribute' or 'all element' practices. Between the two
examples below, which is better/easier/more efficient/flexible for
retrieving information (e.g. with OPENXML). I like the first example
theoretically, but the second is REAL easy to generate (with FOR XML AUTO,
ELEMENTS). Thanks for any tips or insights.
<entities>
<entity>
<entityAttribute>nameOfThisEntity</entityAttribute>
<entityValue>valueOfThisEntity</entityValue>
</entity>
<entity>
<entityAttribute>nameOfNextEntity</entityAttribute>
<entityValue>valueOfNextEntity</entityValue>
</entity>
<entity>
...
</entity>
</entities>
vs.
<entities>
<nameOfThisEntity>valueOfThisEntity</nameOfThisEntity>
<nameOfNextEntity>valueOfNextEntity</nameOfNextEntity>
...
</entities>
Hi Don,
I preferred to the first one, although I do not think there will be much
performance difference between the following two XML structures. The fist
XML structure will be more readable and efficient for search. The following
article will tell you how to optimize SQLXML performance for databases,
including SQL Server 2000.
SQLXML best practice paper on MSDN
http://msdn.microsoft.com/library/de...us/dnsql2k/htm
l/sqlxml_optimperformance.asp?frame=true
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
|||If you plan on using OpenXML, then size and ability to query structure
instead of values will most likely make your second format perform better.
Best regards
Michael
"Don Miller" <nospam@.nospam.com> wrote in message
news:es8k9YfLEHA.2396@.TK2MSFTNGP12.phx.gbl...
> I've created a large XML document from a relational database (using AUTO,
> EXPLICIT, etc.) with many elements, attributes, and subelements but now
> wonder if there is a "best practice" for designing the structure for going
> the other way, XML -> relational. Since I have not yet worked on the data
> extraction side, maybe what I've put together makes data extraction
> awkward
> (requiring many lines of T-SQL vs. one or two). But I definitely cannot
> stomach the 'all attribute' or 'all element' practices. Between the two
> examples below, which is better/easier/more efficient/flexible for
> retrieving information (e.g. with OPENXML). I like the first example
> theoretically, but the second is REAL easy to generate (with FOR XML AUTO,
> ELEMENTS). Thanks for any tips or insights.
> <entities>
> <entity>
> <entityAttribute>nameOfThisEntity</entityAttribute>
> <entityValue>valueOfThisEntity</entityValue>
> </entity>
> <entity>
> <entityAttribute>nameOfNextEntity</entityAttribute>
> <entityValue>valueOfNextEntity</entityValue>
> </entity>
> <entity>
> ...
> </entity>
> </entities>
> vs.
> <entities>
> <nameOfThisEntity>valueOfThisEntity</nameOfThisEntity>
> <nameOfNextEntity>valueOfNextEntity</nameOfNextEntity>
> ...
> </entities>
>

Best practice for handling XML schema hierarchies?

I have a number of tables with columns of xml datatype. Each of these columns are typed against a different XML schema collection. However, each of the XML schema collections contain a hierarchy of schema definitions - and the schemas towards the top of the hierarchy are used by a number of different XML schema collections. I want to define the schemas in such a way that if I need to change a schema towards the top of the hierarchy, I only need to change it in one place.

I understand that it is not possible to reference a schema in one collection from another - is my understanding correct? (If I am wrong, then please disregard the following)

If the schemas must be duplicated in each xml schema collection that needs them, then I am considering the following approach. Are there any better methods available?

- Create a 'reference' xml schema collection that contains all the schemas
- Create a table that relates a schema to all the collections that need it
- Write a stored proc that updates all the individual collections appropriately when the reference collection is updated

Using this method, I would anticipate updating the 'reference' schema and running the stored procedure at a quiet time

I could just use a single collection for everything - but although it would ensure that the contents of a column satisfied a schema - it wouldn't check that it satisfied the correct schema. I guess I could put separate validation on the column to ensure that the right contents had been added, but this seems to run counter to the whole idea of using the XML collections

Any thoughts?

You are correct that you cannot refer to schemas from other schema collections.

You approach of using a master schema collection sounds ok. Alternatively, you could use a special table that contains each one of the schemas in an XML datatype column. That way, you could even perform updates on the schemas programmatically, and you would preserve annotations and comments in the schema as an added bonus.

You then could still do the stored procs.

Note however, that you have to be careful with evolving your schemas in that they should only be gaining new elements and types. Otherwise the schema collection will disallow such updates since the cost of revalidation and potential validation failure of old data was too high for be done implicitly...

Best regards

Michael

|||Thanks Michael - will give it a go

Best method to access web service

We have a billing web service where you passs in the account and amount and get returned an XML string with result.

I had suggested that I open up an endpoint and have the service listen for messages but the programming team wont go for it.

What is the best method for me to call an external web service? I have tried sp_OACreate and run into memory leaks and have not had much luck with assemblies. See http://www.codeproject.com/script/comments/forums.asp?forumid=1725&select=2180035&df=100&msg=2180035

The best method should be assemblies, follow the old post from Vineet: http://blogs.msdn.com/sqlclr/archive/2005/07/25/Vineet.aspx, it shows how to explictly generate the serialization code If I remeber correctly the problem is that the default option for Visual studio projects is to generate code that creates the serialization at runtime, invoking csc.exe on the fly, which clearly won't work for SQL assemblies.

Openning an endpoint (I asumme an HTTP endpoint) won't solve your problem, that is available only for incomming calls (an app can access your SQL endpoint as an WS call) and my understanding is that you want to do it the other way (have a SQL procedure invoke a WS)

Best approach to creating an annotated schema?

I have painfully found out that the schema created from a
dataset.writexmlschema does NOT create an XML schema that can be used with
the XMLBULKLOADER. Does anybody have any insights/code snippets/ideas on ho
w
to create an annotated schema with the 'sql:relation' and 'sql:field'
annotations that are necessary for the xmlbulkloader'You can check out the Books online:
http://msdn.microsoft.com/library/d...ations_0gqb.asp
Bertan ARI
This posting is provided "AS IS" with no warranties, and confers no rights.
"MSSQLServerDeveloper" <MSSQLServerDeveloper@.discussions.microsoft.com>
wrote in message news:51ABC14A-47D6-4F50-8390-F8ADF79B55D9@.microsoft.com...
> I have painfully found out that the schema created from a
> dataset.writexmlschema does NOT create an XML schema that can be used with
> the XMLBULKLOADER. Does anybody have any insights/code snippets/ideas on
how
> to create an annotated schema with the 'sql:relation' and 'sql:field'
> annotations that are necessary for the xmlbulkloader'

Best approach to creating an annotated schema?

I have painfully found out that the schema created from a
dataset.writexmlschema does NOT create an XML schema that can be used with
the XMLBULKLOADER. Does anybody have any insights/code snippets/ideas on how
to create an annotated schema with the 'sql:relation' and 'sql:field'
annotations that are necessary for the xmlbulkloader?
You can check out the Books online:
http://msdn.microsoft.com/library/de...tions_0gqb.asp
Bertan ARI
This posting is provided "AS IS" with no warranties, and confers no rights.
"MSSQLServerDeveloper" <MSSQLServerDeveloper@.discussions.microsoft.com>
wrote in message news:51ABC14A-47D6-4F50-8390-F8ADF79B55D9@.microsoft.com...
> I have painfully found out that the schema created from a
> dataset.writexmlschema does NOT create an XML schema that can be used with
> the XMLBULKLOADER. Does anybody have any insights/code snippets/ideas on
how
> to create an annotated schema with the 'sql:relation' and 'sql:field'
> annotations that are necessary for the xmlbulkloader?

Best and quickest approach to importing thousands of 2 meg XML files into XMl column?

Hi all,
I intend to use SQL Server 2005 (which I haven't used before), to store hundreds of thousands of XML files this autumn and I'm trying to figure out which approach is the best to do this. These files are very complex (multiple nested elements) and use multiple namespaces (imports).The files will be on the same server as the Database. Below is a list of some ideas I have.

1) Use Some DTS process to import the XML files if possible in SQL Server 2005?
2) Create a stored procedure that interates through a local directory, opens each XML file and inserts it's content into the database column using the bulkload method (any examples would be appreciated). Does this require the use of some scripting code such as VB script?
3) Run a server-side script such as PHP that loops through a local directory and stores the content of the XML file into a variable which is passed to a Stored procedure which stores the variable in to the database column? I have tried this and it seems very unstable and slow, roughly 2 minutes per file (the application server and database servers are on different boxes). I'm worried when I need to loop through thousands of files it will crash the servers!

Any suggestions would be appreciated

Muhi

Muhi,

SQL Server provides a command line tool called 'BCP' which is one of the good ways to bulk load XML data into an XML column. For instance you can store your XML instances in a file with a delimiter inbetween each instance (default delimiter is ,) and you can use the following command to bulk load your data:

bcp YourDB..YourTable in "XMLData.csv" -T -b 300 -N -h "TABLOCK"

This will insert the instances from 'XMLData.csv' into 'YourTable' in database 'YourDB'. BOL has a lot more information about the command line options in BCP. There are also more hints you can provide to BCP to improve performance. For instance if you have a clustered index on the table and if you know that your input data in the file is ordered on the index column (say id) then you can provide another hint to BCP -h "ORDER(id)" to avoid some additional sorts.

Thanks

Babu

|||

Hi Muhi,

try SQL Server 2005 Books Online

Examples of Bulk Importing and Exporting XML Documents

http://msdn2.microsoft.com/en-us/library/ms191184.aspx

Best regards

Jiri

Benefits of using SQL over XML

Hi,

I have a question relating to XML and SQL. My company currently runs a website which allows its clients to log in, view their accounts and transaction history online. The website is totally read only with the exception of changing passwords.

The data is taken from our back office system overnight which runs an oracle 8i database (we cannot like our website to the database due to the agreement we have in place with our software supplier). The data is written to a CSV file which is then converted into XML. The XML file is saved to the webserver and is referenced by the website.

The structure of the website has a relationship where the Client has a Manager who can see their clients accounts, a Branch level that can see all of their Managers and the underlying clients and then finally a company level that sees everything.

We are finding that using XML is causing a real issue in performance and I was wondering if migrating the website to SQL server would improve the performance of the queries etc .

Any advice would be gratefully recieved

Lee

It really depends on two things: The application and the version of SQL Server you are using. For certain input/retrieval methods, XML can actually be faster than using direct database calls. SQL Server 2005 has native XML features, which you can read more about here:

http://www.sqlsummit.com/People/MRys.htm

Buck

|||

The thing is that our website is taking considerably longer to return results using XML. Our software provider can provide a website which uses Oracle and an example website using test data seems to query and return the data back in far less time then ours using XML. But this site is a lot more costly option and does not provide all the functionalty we require. The main reason for the performance increase is that we want to be able to use the website internally for our branches and front office staff, so performance is key it will have about 20 - 30 users. We are planning to do this because we are unable to restrict access to parts of our back office system from the front office staff. The problem with the performance of the website currently means that the staff will have to deal with a sluggish system.

Our website designer has said that he would have to rewrite the website to change it from XML to SQL, would XQuery be a simpler solution. We are within reason happy to purchase whatever software is required to make this work.

|||

Again, it all depends on how the application is coded. Simply changing from XML to an RDBMS query doesn't guarentee that one will be faster than the other. In other words, you can code an application to be faster in either case.

If performance is key, then for large data sets a database platform might be the way to go. If you need to share data between multiple systems, then XML might be the way to go. It all depends on your needs, but in either case you'll want to evaluate your code to ensure that it is as optimal as possible for your situation.

Benchmarks for XML EXPLICIT vs. standard recordset?

Hello all.
I was wondering if anyone had links and/or information regarding SQL Server
2000 performance benchmarks when it comes to using FOR XML EXPLICIT
techniques versus using a standard recordset. I've built a number of stored
procs at work using FOR XML EXPLICIT and it's been a huge time-saver. But
alas, the DBAs are unfamiliar (and thus "uncomfortable") with my use of these
techniques.
The alternative, manually building an XML document from recordsets on the VB.
NET side, seems sloppy and cumbersome to me. I'm hoping I can garner some
ammunition that supports FOR XML EXPLICIT.I haven't seen any performance figures (but you might want to re-post in the
.sqlserver.xml group just to make sure). If I were you, I would run some
load tests on both the XML procedures and equivalent rowset procedures to
show whether or not the XML will cause a performance problem.
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--
"Frefaln via SQLMonster.com" <forum@.SQLMonster.com> wrote in message
news:52BBD3DFC1848@.SQLMonster.com...
> Hello all.
> I was wondering if anyone had links and/or information regarding SQL
Server
> 2000 performance benchmarks when it comes to using FOR XML EXPLICIT
> techniques versus using a standard recordset. I've built a number of
stored
> procs at work using FOR XML EXPLICIT and it's been a huge time-saver. But
> alas, the DBAs are unfamiliar (and thus "uncomfortable") with my use of
these
> techniques.
> The alternative, manually building an XML document from recordsets on the
VB.
> NET side, seems sloppy and cumbersome to me. I'm hoping I can garner some
> ammunition that supports FOR XML EXPLICIT.

Benchmarks for XML EXPLICIT vs. standard recordset?

Hello all.
I was wondering if anyone had links and/or information regarding SQL Server
2000 performance benchmarks when it comes to using FOR XML EXPLICIT
techniques versus using a standard recordset. I've built a number of stored
procs at work using FOR XML EXPLICIT and it's been a huge time-saver. But
alas, the DBAs are unfamiliar (and thus "uncomfortable") with my use of these
techniques.
The alternative, manually building an XML document from recordsets on the VB.
NET side, seems sloppy and cumbersome to me. I'm hoping I can garner some
ammunition that supports FOR XML EXPLICIT.
I haven't seen any performance figures (but you might want to re-post in the
..sqlserver.xml group just to make sure). If I were you, I would run some
load tests on both the XML procedures and equivalent rowset procedures to
show whether or not the XML will cause a performance problem.
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
"Frefaln via droptable.com" <forum@.droptable.com> wrote in message
news:52BBD3DFC1848@.droptable.com...
> Hello all.
> I was wondering if anyone had links and/or information regarding SQL
Server
> 2000 performance benchmarks when it comes to using FOR XML EXPLICIT
> techniques versus using a standard recordset. I've built a number of
stored
> procs at work using FOR XML EXPLICIT and it's been a huge time-saver. But
> alas, the DBAs are unfamiliar (and thus "uncomfortable") with my use of
these
> techniques.
> The alternative, manually building an XML document from recordsets on the
VB.
> NET side, seems sloppy and cumbersome to me. I'm hoping I can garner some
> ammunition that supports FOR XML EXPLICIT.

Benchmarks for XML EXPLICIT vs. standard recordset?

Hello all.
I was wondering if anyone had links and/or information regarding SQL Server
2000 performance benchmarks when it comes to using FOR XML EXPLICIT
techniques versus using a standard recordset. I've built a number of stored
procs at work using FOR XML EXPLICIT and it's been a huge time-saver. But
alas, the DBAs are unfamiliar (and thus "uncomfortable") with my use of thes
e
techniques.
The alternative, manually building an XML document from recordsets on the VB
.
NET side, seems sloppy and cumbersome to me. I'm hoping I can garner some
ammunition that supports FOR XML EXPLICIT.I haven't seen any performance figures (but you might want to re-post in the
.sqlserver.xml group just to make sure). If I were you, I would run some
load tests on both the XML procedures and equivalent rowset procedures to
show whether or not the XML will cause a performance problem.
Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--
"Frefaln via droptable.com" <forum@.droptable.com> wrote in message
news:52BBD3DFC1848@.droptable.com...
> Hello all.
> I was wondering if anyone had links and/or information regarding SQL
Server
> 2000 performance benchmarks when it comes to using FOR XML EXPLICIT
> techniques versus using a standard recordset. I've built a number of
stored
> procs at work using FOR XML EXPLICIT and it's been a huge time-saver. But
> alas, the DBAs are unfamiliar (and thus "uncomfortable") with my use of
these
> techniques.
> The alternative, manually building an XML document from recordsets on the
VB.
> NET side, seems sloppy and cumbersome to me. I'm hoping I can garner some
> ammunition that supports FOR XML EXPLICIT.