Showing posts with label col1. Show all posts
Showing posts with label col1. Show all posts

Wednesday, March 21, 2012

Dumping Data from a XML file to DB Tables

Hi All ,

I have an XML file saved in my machine at c:\MyXML.xml . I have two tables in my DB as Table1 ( [col1],[col2]) & Table2()[col1],[col2] . I have to dump the data from this xml file to these two tables in one shot .The format of the XML file MyXML.xml is something like this :

<?xml version = "1.0">

-<Report xmlns = " MyReport".......... >

- <table1>

- <Data>

<Record col1 = "A" col2 = "B" / >

<Record col1 = "C" col2 = "D" / >

<Record col1 = "E" col2 = "F" / >

</Data>

</table1>

- <table2>

- <Data>

<Record col1 = "A" col2 = "B" / >

<Record col1 = "C" col2 = "D" / >

<Record col1 = "E" col2 = "F" / >

</Data>

</table2>

</Report>

Plz suggest me some possible ways to get this done . I m using sql 2005.

Thanks in advance for the help.

Here is a complete example, you can use the OPENXML statement after the stored procedure sp_xml_preparedocument has parsed the XML:

Code Snippet

CREATE TABLE table1 (

col1 nvarchar(10),

col2 nvarchar(10)

);

CREATE TABLE table2 (

col1 nvarchar(10),

col2 nvarchar(10)

);

DECLARE @.xmlDocument xml;

SET @.xmlDocument = '<Report xmlns="MyReport">

<table1>

<Data>

<Record col1 = "A" col2 = "B" />

<Record col1 = "C" col2 = "D" />

<Record col1 = "E" col2 = "F" />

</Data>

</table1>

<table2>

<Data>

<Record col1 = "A" col2 = "B" />

<Record col1 = "C" col2 = "D" />

<Record col1 = "E" col2 = "F" />

</Data>

</table2>

</Report>';

DECLARE @.docHandle int;

EXEC sp_xml_preparedocument @.docHandle OUTPUT, @.xmlDocument, N'<Report xmlns:ns1="MyReport"/>';

INSERT INTO table1

SELECT *

FROM OPENXML (@.docHandle, N'/ns1:Report/ns1:table1/ns1:Data/ns1:Record', 0)

WITH table1;

INSERT INTO table2

SELECT *

FROM OPENXML (@.docHandle, N'/ns1:Report/ns1:table2/ns1:Data/ns1:Record', 0)

WITH table2;

EXEC sp_xml_removedocument @.docHandle;

SELECT col1, col2 FROM table1;

SELECT col1, col2 FROM table2

Sunday, March 11, 2012

Dumb index question

If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
indexes?
Even if it only creates one compound index, if I run the query: select *
from tab1 where col1 = x
Will it still use the compound index, if nothing better is available,
because the column heads the index.
I am expecting the answer to be: 2 indexes and Duh/yes!On Wed, 15 Aug 2007 16:42:16 -0700, "Jay" <nospam@.nospam.org> wrote:

>If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
>another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
>indexes?
>Even if it only creates one compound index, if I run the query: select *
>from tab1 where col1 = x
>Will it still use the compound index, if nothing better is available,
>because the column heads the index.
>
>I am expecting the answer to be: 2 indexes and Duh/yes!
A compound index is one index, so if the only index you create is a
two column primary key there is one index. A foreign key is a good
candidate for an index, but no index ix created just because of a FK
definition. Only a PK definition creates an index.
A multi-column index can be used if at least the left-most column is
provided to search on. So in your example of a compound PK on
tab1(col1, col2), the query SELECT * FROM tab1 WHERE col1 = 'x' can
use the index.
Roy Harvey
Beacon Falls, CT|||In addition to Roy's answer , try to avoid using SELECT * in production
environment.
Always specify columns that you need to return. For example if you run
SELECT col1,col2 FROM tbl WHERE col2='blblbl' then SQL Server will create
most fate execution plan as your index covers columns in SELECT statement.
But if you run SELECT col10 FROM tbl WHERE col2='blblbl' will use bookmark
to clustered index key (contains data) to return the data from col10 which
is not part of index
Just my two cenys
"Jay" <nospam@.nospam.org> wrote in message
news:e9LqqX53HHA.600@.TK2MSFTNGP05.phx.gbl...
> If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
> another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
> indexes?
> Even if it only creates one compound index, if I run the query: select *
> from tab1 where col1 = x
> Will it still use the compound index, if nothing better is available,
> because the column heads the index.
>
> I am expecting the answer to be: 2 indexes and Duh/yes!
>|||On Aug 15, 6:42 pm, "Jay" <nos...@.nospam.org> wrote:
> If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
> another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
> indexes?
> Even if it only creates one compound index, if I run the query: select *
> from tab1 where col1 = x
> Will it still use the compound index, if nothing better is available,
> because the column heads the index.
> I am expecting the answer to be: 2 indexes and Duh/yes!
It is very easy to see for yourself. Create a FK constraint and see if
it created an index. You may use GUI or select from system views such
as sysindexes and sysindexkeys.
Alex Kuznetsov, SQL Server MVP
http://sqlserver-tips.blogspot.com/

Dumb index question

If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
indexes?
Even if it only creates one compound index, if I run the query: select *
from tab1 where col1 = x
Will it still use the compound index, if nothing better is available,
because the column heads the index.
I am expecting the answer to be: 2 indexes and Duh/yes!
On Wed, 15 Aug 2007 16:42:16 -0700, "Jay" <nospam@.nospam.org> wrote:

>If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
>another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
>indexes?
>Even if it only creates one compound index, if I run the query: select *
>from tab1 where col1 = x
>Will it still use the compound index, if nothing better is available,
>because the column heads the index.
>
>I am expecting the answer to be: 2 indexes and Duh/yes!
A compound index is one index, so if the only index you create is a
two column primary key there is one index. A foreign key is a good
candidate for an index, but no index ix created just because of a FK
definition. Only a PK definition creates an index.
A multi-column index can be used if at least the left-most column is
provided to search on. So in your example of a compound PK on
tab1(col1, col2), the query SELECT * FROM tab1 WHERE col1 = 'x' can
use the index.
Roy Harvey
Beacon Falls, CT
|||In addition to Roy's answer , try to avoid using SELECT * in production
environment.
Always specify columns that you need to return. For example if you run
SELECT col1,col2 FROM tbl WHERE col2='blblbl' then SQL Server will create
most fate execution plan as your index covers columns in SELECT statement.
But if you run SELECT col10 FROM tbl WHERE col2='blblbl' will use bookmark
to clustered index key (contains data) to return the data from col10 which
is not part of index
Just my two cenys
"Jay" <nospam@.nospam.org> wrote in message
news:e9LqqX53HHA.600@.TK2MSFTNGP05.phx.gbl...
> If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
> another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
> indexes?
> Even if it only creates one compound index, if I run the query: select *
> from tab1 where col1 = x
> Will it still use the compound index, if nothing better is available,
> because the column heads the index.
>
> I am expecting the answer to be: 2 indexes and Duh/yes!
>
|||On Aug 15, 6:42 pm, "Jay" <nos...@.nospam.org> wrote:
> If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
> another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
> indexes?
> Even if it only creates one compound index, if I run the query: select *
> from tab1 where col1 = x
> Will it still use the compound index, if nothing better is available,
> because the column heads the index.
> I am expecting the answer to be: 2 indexes and Duh/yes!
It is very easy to see for yourself. Create a FK constraint and see if
it created an index. You may use GUI or select from system views such
as sysindexes and sysindexkeys.
Alex Kuznetsov, SQL Server MVP
http://sqlserver-tips.blogspot.com/

Dumb index question

If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
indexes?
Even if it only creates one compound index, if I run the query: select *
from tab1 where col1 = x
Will it still use the compound index, if nothing better is available,
because the column heads the index.
I am expecting the answer to be: 2 indexes and Duh/yes!On Wed, 15 Aug 2007 16:42:16 -0700, "Jay" <nospam@.nospam.org> wrote:
>If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
>another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
>indexes?
>Even if it only creates one compound index, if I run the query: select *
>from tab1 where col1 = x
>Will it still use the compound index, if nothing better is available,
>because the column heads the index.
>
>I am expecting the answer to be: 2 indexes and Duh/yes!
A compound index is one index, so if the only index you create is a
two column primary key there is one index. A foreign key is a good
candidate for an index, but no index ix created just because of a FK
definition. Only a PK definition creates an index.
A multi-column index can be used if at least the left-most column is
provided to search on. So in your example of a compound PK on
tab1(col1, col2), the query SELECT * FROM tab1 WHERE col1 = 'x' can
use the index.
Roy Harvey
Beacon Falls, CT|||In addition to Roy's answer , try to avoid using SELECT * in production
environment.
Always specify columns that you need to return. For example if you run
SELECT col1,col2 FROM tbl WHERE col2='blblbl' then SQL Server will create
most fate execution plan as your index covers columns in SELECT statement.
But if you run SELECT col10 FROM tbl WHERE col2='blblbl' will use bookmark
to clustered index key (contains data) to return the data from col10 which
is not part of index
Just my two cenys
"Jay" <nospam@.nospam.org> wrote in message
news:e9LqqX53HHA.600@.TK2MSFTNGP05.phx.gbl...
> If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
> another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
> indexes?
> Even if it only creates one compound index, if I run the query: select *
> from tab1 where col1 = x
> Will it still use the compound index, if nothing better is available,
> because the column heads the index.
>
> I am expecting the answer to be: 2 indexes and Duh/yes!
>|||On Aug 15, 6:42 pm, "Jay" <nos...@.nospam.org> wrote:
> If I create a compound PK on tab1(col1, col2) where col1 is also a FK to
> another table, is SQL Server 2000 (or 2005) creating 1, or 2 underlying
> indexes?
> Even if it only creates one compound index, if I run the query: select *
> from tab1 where col1 = x
> Will it still use the compound index, if nothing better is available,
> because the column heads the index.
> I am expecting the answer to be: 2 indexes and Duh/yes!
It is very easy to see for yourself. Create a FK constraint and see if
it created an index. You may use GUI or select from system views such
as sysindexes and sysindexkeys.
Alex Kuznetsov, SQL Server MVP
http://sqlserver-tips.blogspot.com/