Correcting old data

Hi,
What's the best way to handle data reloads when you have implemented Type 2
slowly changing dimension?
For example, you might have an Account dimension, with a status of open or
closed. Someone accidentally closes the account, which we then extract and
update, creating a new record. They then realise the mistake and re-open the
account. The next extract would be create a third record, with the original
value.
On top of this, fact data may have been loaded against the second (invalid)
record.
If the source system doesn't keep a history of these changes, then we can't
redo the extract because it will contain a mix of valid and invalid changes.
Thanks,
Wreck.Hello Wreck,
Have you considered type 1 for dimensions that are affected by this
issue? This way the transactions are not effected. You can have a
mixture of type 1 and 2 in your stars.
Check out:
http://bi-on-sql-server.blogspot.co...r.blogspot.com/|||Hi Wreck,
you are entering 'religious territory' ground.....
There are two religions here:
1. Go back and correct data 'known to be incorrect'.
2. Retain data known to be incorrect and enter new transactions which
update the DW such that it now represents the data 'known' to be
correct. (Which is really just 'thought to be correct now'.)
I come down in the camp of retain the incorrect data and enter new
transactions such the data is now set to the 'thought to be correct
value'. In your case, the account would be 're-opened' and it would
occur as 're-opened'.
Why?
Because going back and updating data is a very slippery slope. Where
does it end? And if decisions were made against data that was presented
at a certain point in time and then the underlying data is 'corrected'
and people come along to review those decisions and the data says
'these decisions are not well founded on the data' what does one do?
One must remember that data is never, ever 'true' or 'correct' it is
only ever 'thought to be correct/true' which means that data that we
have realised is incorrect and we now believe to be true has the same
likelyhood of being incorrect as the data we just changed....
Whereas, if we retain the fact that we found data to be incorrect and
we enter transactions to place new transactions to correct that data we
can see the information on which decisions were taken at the time. We
can also see how often data is being corrected....perhaps there are
underlying issues for a high rate of data corrections occurring such as
lack of proper training in the call centers taking calls and entering
data? It happens...
In some cases it is a legal requirement not to correct historical data.
For example, in most countries it is illegal to update the financial
statements of a company after the close of the annual accounts...yet
clearly there have been some very 'incorrect' entries in the financials
of some very large companies over the last few years.
Best Regards
Peter Nolan
www.peternolan.com|||Thanks for your feedback guys.
Myles, the system currently has Type I changes across the board, and
naturally doesn't track history very well. I want to implement Type II, but
the data in the source systems has its issues, hence my concerns.
There are steps being taken to improve the data quality in the source system
s.
Peter, I'm inclined to agree with you that we don't correct anything,
especially once it's been reported on. However, the business is still fairly
new to the whole warehouse concept - prior to this, it was the usual story o
f
lots of Access and Excel apps extracting and manipulating data for reporting
.
When these data errors are found, they don't really understand why it's so
difficult to make a correction.
Thanks,
Wreck.
"Peter Nolan" wrote:

> Hi Wreck,
> you are entering 'religious territory' ground.....
> There are two religions here:
> 1. Go back and correct data 'known to be incorrect'.
> 2. Retain data known to be incorrect and enter new transactions which
> update the DW such that it now represents the data 'known' to be
> correct. (Which is really just 'thought to be correct now'.)
> I come down in the camp of retain the incorrect data and enter new
> transactions such the data is now set to the 'thought to be correct
> value'. In your case, the account would be 're-opened' and it would
> occur as 're-opened'.
> Why?
> Because going back and updating data is a very slippery slope. Where
> does it end? And if decisions were made against data that was presented
> at a certain point in time and then the underlying data is 'corrected'
> and people come along to review those decisions and the data says
> 'these decisions are not well founded on the data' what does one do?
> One must remember that data is never, ever 'true' or 'correct' it is
> only ever 'thought to be correct/true' which means that data that we
> have realised is incorrect and we now believe to be true has the same
> likelyhood of being incorrect as the data we just changed....
> Whereas, if we retain the fact that we found data to be incorrect and
> we enter transactions to place new transactions to correct that data we
> can see the information on which decisions were taken at the time. We
> can also see how often data is being corrected....perhaps there are
> underlying issues for a high rate of data corrections occurring such as
> lack of proper training in the call centers taking calls and entering
> data? It happens...
> In some cases it is a legal requirement not to correct historical data.
> For example, in most countries it is illegal to update the financial
> statements of a company after the close of the annual accounts...yet
> clearly there have been some very 'incorrect' entries in the financials
> of some very large companies over the last few years.
> Best Regards
> Peter Nolan
> www.peternolan.com
>|||Hi Wreck,
I have been doing DWing for 15 years...and I have seen a great many
cases of significant destruction of value within a company on the basis
that 'the business users do not understand'.......and I have seen
even more because 'the IT people do not understand'.!!!... ;-)
Indeed, it seems that those who 'do not understand' seem to think the
onus is on those who 'do understand' to explain to them what it is that
is not understood to persuade them not to destroy value in their
company. Those who 'do not understand' do not seem to think the onus
is on them to make an effort to understand to assist them create value
in their company...and so value is commonly destroyed....it would be
funnier if it was not so common...(LOL)!!
You are lucky in that today there are tons of materials available on
reasonable practices for DW development.
However, what is published is never the 'leading edge' and is rarely
'best practice'.
'Leading edge' and 'Best Practice' are retained within companies for
competitive advantage...;-)
Best Regards
Peter Nolan
www.peternolan.com

Correcting old data

Hi,
What's the best way to handle data reloads when you have implemented Type 2
slowly changing dimension?
For example, you might have an Account dimension, with a status of open or
closed. Someone accidentally closes the account, which we then extract and
update, creating a new record. They then realise the mistake and re-open the
account. The next extract would be create a third record, with the original
value.
On top of this, fact data may have been loaded against the second (invalid)
record.
If the source system doesn't keep a history of these changes, then we can't
redo the extract because it will contain a mix of valid and invalid changes.
Thanks,
Wreck.
Hello Wreck,
Have you considered type 1 for dimensions that are affected by this
issue? This way the transactions are not effected. You can have a
mixture of type 1 and 2 in your stars.
Check out:
http://bi-on-sql-server.blogspot.com...-changing.html
I wrote a blog on type 2 and type 1.
Type 2 only works at the point of time for the extracts as you
mentioned. One way of resolving this problem with dirty changes is to
take more frequent extracts to capture more of the changes.
Another option is to remove dirty changes from the dimension if there
are no corresponding fact transactions.
Hope this helps
Myles Matheson
Data Warehouse Architect
http://bi-on-sql-server.blogspot.com/
|||Hi Wreck,
you are entering 'religious territory' ground.....
There are two religions here:
1. Go back and correct data 'known to be incorrect'.
2. Retain data known to be incorrect and enter new transactions which
update the DW such that it now represents the data 'known' to be
correct. (Which is really just 'thought to be correct now'.)
I come down in the camp of retain the incorrect data and enter new
transactions such the data is now set to the 'thought to be correct
value'. In your case, the account would be 're-opened' and it would
occur as 're-opened'.
Why?
Because going back and updating data is a very slippery slope. Where
does it end? And if decisions were made against data that was presented
at a certain point in time and then the underlying data is 'corrected'
and people come along to review those decisions and the data says
'these decisions are not well founded on the data' what does one do?
One must remember that data is never, ever 'true' or 'correct' it is
only ever 'thought to be correct/true' which means that data that we
have realised is incorrect and we now believe to be true has the same
likelyhood of being incorrect as the data we just changed....
Whereas, if we retain the fact that we found data to be incorrect and
we enter transactions to place new transactions to correct that data we
can see the information on which decisions were taken at the time. We
can also see how often data is being corrected....perhaps there are
underlying issues for a high rate of data corrections occurring such as
lack of proper training in the call centers taking calls and entering
data? It happens...
In some cases it is a legal requirement not to correct historical data.
For example, in most countries it is illegal to update the financial
statements of a company after the close of the annual accounts...yet
clearly there have been some very 'incorrect' entries in the financials
of some very large companies over the last few years.
Best Regards
Peter Nolan
www.peternolan.com
|||Thanks for your feedback guys.
Myles, the system currently has Type I changes across the board, and
naturally doesn't track history very well. I want to implement Type II, but
the data in the source systems has its issues, hence my concerns.
There are steps being taken to improve the data quality in the source systems.
Peter, I'm inclined to agree with you that we don't correct anything,
especially once it's been reported on. However, the business is still fairly
new to the whole warehouse concept - prior to this, it was the usual story of
lots of Access and Excel apps extracting and manipulating data for reporting.
When these data errors are found, they don't really understand why it's so
difficult to make a correction.
Thanks,
Wreck.
"Peter Nolan" wrote:

> Hi Wreck,
> you are entering 'religious territory' ground.....
> There are two religions here:
> 1. Go back and correct data 'known to be incorrect'.
> 2. Retain data known to be incorrect and enter new transactions which
> update the DW such that it now represents the data 'known' to be
> correct. (Which is really just 'thought to be correct now'.)
> I come down in the camp of retain the incorrect data and enter new
> transactions such the data is now set to the 'thought to be correct
> value'. In your case, the account would be 're-opened' and it would
> occur as 're-opened'.
> Why?
> Because going back and updating data is a very slippery slope. Where
> does it end? And if decisions were made against data that was presented
> at a certain point in time and then the underlying data is 'corrected'
> and people come along to review those decisions and the data says
> 'these decisions are not well founded on the data' what does one do?
> One must remember that data is never, ever 'true' or 'correct' it is
> only ever 'thought to be correct/true' which means that data that we
> have realised is incorrect and we now believe to be true has the same
> likelyhood of being incorrect as the data we just changed....
> Whereas, if we retain the fact that we found data to be incorrect and
> we enter transactions to place new transactions to correct that data we
> can see the information on which decisions were taken at the time. We
> can also see how often data is being corrected....perhaps there are
> underlying issues for a high rate of data corrections occurring such as
> lack of proper training in the call centers taking calls and entering
> data? It happens...
> In some cases it is a legal requirement not to correct historical data.
> For example, in most countries it is illegal to update the financial
> statements of a company after the close of the annual accounts...yet
> clearly there have been some very 'incorrect' entries in the financials
> of some very large companies over the last few years.
> Best Regards
> Peter Nolan
> www.peternolan.com
>
|||Hi Wreck,
I have been doing DWing for 15 years...and I have seen a great many
cases of significant destruction of value within a company on the basis
that 'the business users do not understand'.......and I have seen
even more because 'the IT people do not understand'.!!!... ;-)
Indeed, it seems that those who 'do not understand' seem to think the
onus is on those who 'do understand' to explain to them what it is that
is not understood to persuade them not to destroy value in their
company. Those who 'do not understand' do not seem to think the onus
is on them to make an effort to understand to assist them create value
in their company...and so value is commonly destroyed....it would be
funnier if it was not so common...(LOL)!!
You are lucky in that today there are tons of materials available on
reasonable practices for DW development.
However, what is published is never the 'leading edge' and is rarely
'best practice'.
'Leading edge' and 'Best Practice' are retained within companies for
competitive advantage...;-)
Best Regards
Peter Nolan
www.peternolan.com

copying table to new schema not working

SQL 7.0
Trying to copy a table to a table with different schema
and getting an error.
Old Schema example
Name, char, 30 NOT NULL
address, char, 30 NOT NULL
New Schema
Name,char, 30 NOT NULL
id,number,10 NULL ..........new field
address, char, 30 NOT NULL
I had imagined that the fields that were common would
copy and the new field "ID" would not fill in. I'm pretty
sure my test worked yesterday, but today, it fails with
the error that old.address is trying to copy to
new.number and it fails.
There are roughly 100 million rows and if I try to modify
the old table directly by adding the ID field, SQL
eventually gives some kind of LOG error.
Any suggestions on how to convert this table to the new
schema?
Thanks,
DonFirst of all, there is no datatype in SQL Server called 'number'. I'm not
sure why you're not getting an error as a result of that. Second, how are
you doing this copy? Can you post code and/or what method you're using?
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
> SQL 7.0
> Trying to copy a table to a table with different schema
> and getting an error.
> Old Schema example
> Name, char, 30 NOT NULL
> address, char, 30 NOT NULL
> New Schema
> Name,char, 30 NOT NULL
> id,number,10 NULL ..........new field
> address, char, 30 NOT NULL
> I had imagined that the fields that were common would
> copy and the new field "ID" would not fill in. I'm pretty
> sure my test worked yesterday, but today, it fails with
> the error that old.address is trying to copy to
> new.number and it fails.
> There are roughly 100 million rows and if I try to modify
> the old table directly by adding the ID field, SQL
> eventually gives some kind of LOG error.
> Any suggestions on how to convert this table to the new
> schema?
> Thanks,
> Don
>
>|||"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
> SQL 7.0
> Trying to copy a table to a table with different schema
> and getting an error.
> Old Schema example
> Name, char, 30 NOT NULL
> address, char, 30 NOT NULL
> New Schema
> Name,char, 30 NOT NULL
> id,number,10 NULL ..........new field
> address, char, 30 NOT NULL
> I had imagined that the fields that were common would
> copy and the new field "ID" would not fill in. I'm pretty
> sure my test worked yesterday, but today, it fails with
> the error that old.address is trying to copy to
> new.number and it fails.
> There are roughly 100 million rows and if I try to modify
> the old table directly by adding the ID field, SQL
> eventually gives some kind of LOG error.
> Any suggestions on how to convert this table to the new
> schema?
> Thanks,
> Don
>
>
How are you trying to copy it?
Are you using SEM to try to add the new field?
How about running:
ALTER TABLE ADD id numeric(x,y) NULL
Other choices that can avoid the LOG error issues..
BCP the data out.
TRUNCATE the table.
ALTER TABLE to add the column.
Remove indexes
BULK INSERT the data back in.
Recreate your indexes.
HTH
Rick Sawtell
MCT, MCSD, MCDBA|||I'd been using DTS to copy. Are you saying BULK copy will
not have the same LOG filling up problems?
>--Original Message--
>"Don" <anonymous@.discussions.microsoft.com> wrote in
message
>news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
>> SQL 7.0
>> Trying to copy a table to a table with different schema
>> and getting an error.
>> Old Schema example
>> Name, char, 30 NOT NULL
>> address, char, 30 NOT NULL
>> New Schema
>> Name,char, 30 NOT NULL
>> id,number,10 NULL ..........new field
>> address, char, 30 NOT NULL
>> I had imagined that the fields that were common would
>> copy and the new field "ID" would not fill in. I'm
pretty
>> sure my test worked yesterday, but today, it fails with
>> the error that old.address is trying to copy to
>> new.number and it fails.
>> There are roughly 100 million rows and if I try to
modify
>> the old table directly by adding the ID field, SQL
>> eventually gives some kind of LOG error.
>> Any suggestions on how to convert this table to the new
>> schema?
>> Thanks,
>> Don
>>
>How are you trying to copy it?
>Are you using SEM to try to add the new field?
>How about running:
>ALTER TABLE ADD id numeric(x,y) NULL
>Other choices that can avoid the LOG error issues..
>BCP the data out.
>TRUNCATE the table.
>ALTER TABLE to add the column.
>Remove indexes
>BULK INSERT the data back in.
>Recreate your indexes.
>
>HTH
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>
>.
>|||"number" was just an example of a field type and not to
be taken literally.
Using DTS to do the copy. Just exporting from Source and
Destination, and then choosing the table to copy from and
the new table to copy to which has the new schema.
>--Original Message--
>First of all, there is no datatype in SQL Server
called 'number'. I'm not
>sure why you're not getting an error as a result of
that. Second, how are
>you doing this copy? Can you post code and/or what
method you're using?
>
>--
>Adam Machanic
>SQL Server MVP
>http://www.sqljunkies.com/weblog/amachanic
>--
>
>"Don" <anonymous@.discussions.microsoft.com> wrote in
message
>news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
>> SQL 7.0
>> Trying to copy a table to a table with different schema
>> and getting an error.
>> Old Schema example
>> Name, char, 30 NOT NULL
>> address, char, 30 NOT NULL
>> New Schema
>> Name,char, 30 NOT NULL
>> id,number,10 NULL ..........new field
>> address, char, 30 NOT NULL
>> I had imagined that the fields that were common would
>> copy and the new field "ID" would not fill in. I'm
pretty
>> sure my test worked yesterday, but today, it fails with
>> the error that old.address is trying to copy to
>> new.number and it fails.
>> There are roughly 100 million rows and if I try to
modify
>> the old table directly by adding the ID field, SQL
>> eventually gives some kind of LOG error.
>> Any suggestions on how to convert this table to the new
>> schema?
>> Thanks,
>> Don
>>
>
>.
>|||<anonymous@.discussions.microsoft.com> wrote in message
news:008701c4c82c$0d365fc0$a501280a@.phx.gbl...
> I'd been using DTS to copy. Are you saying BULK copy will
> not have the same LOG filling up problems?
>
>>--Original Message--
>>"Don" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
>> SQL 7.0
>> Trying to copy a table to a table with different schema
>> and getting an error.
>> Old Schema example
>> Name, char, 30 NOT NULL
>> address, char, 30 NOT NULL
>> New Schema
>> Name,char, 30 NOT NULL
>> id,number,10 NULL ..........new field
>> address, char, 30 NOT NULL
>> I had imagined that the fields that were common would
>> copy and the new field "ID" would not fill in. I'm
> pretty
>> sure my test worked yesterday, but today, it fails with
>> the error that old.address is trying to copy to
>> new.number and it fails.
>> There are roughly 100 million rows and if I try to
> modify
>> the old table directly by adding the ID field, SQL
>> eventually gives some kind of LOG error.
>> Any suggestions on how to convert this table to the new
>> schema?
>> Thanks,
>> Don
It depends on how you do the package.
DTS (if you look closely) will use BCP in a lot of cases.
Take a look at "Logged Bulk Copy" in the BOL. It should show you how to do
a minimally logged BCP command. BULK INSERT is generally faster however, so
keep that option in mind as well.
HTH
Rick Sawtell
MCT, MCSD, MCDBA|||The BULK COPY is nice and all, but why add an unnecessary field to an old
schema?
The problem with your DTS is that you haven't properly mapped the source
columns to the destination columns.
You could just use a straight INSERT statement.
INSERT INTO newschema.MyTable(name, address)
SELECT name, address
FROM oldschema.MyTable
Sincerely,
Anthony Thomas
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
> SQL 7.0
> Trying to copy a table to a table with different schema
> and getting an error.
> Old Schema example
> Name, char, 30 NOT NULL
> address, char, 30 NOT NULL
> New Schema
> Name,char, 30 NOT NULL
> id,number,10 NULL ..........new field
> address, char, 30 NOT NULL
> I had imagined that the fields that were common would
> copy and the new field "ID" would not fill in. I'm pretty
> sure my test worked yesterday, but today, it fails with
> the error that old.address is trying to copy to
> new.number and it fails.
> There are roughly 100 million rows and if I try to modify
> the old table directly by adding the ID field, SQL
> eventually gives some kind of LOG error.
> Any suggestions on how to convert this table to the new
> schema?
> Thanks,
> Don
>
>|||This might be a rediculous question, but if I detach and
reattach the log file to a larger hard drive with a lot
of space...i shouldn't get the out of LOG space message?
Is this a "duh" question?
Don
>--Original Message--
><anonymous@.discussions.microsoft.com> wrote in message
>news:008701c4c82c$0d365fc0$a501280a@.phx.gbl...
>> I'd been using DTS to copy. Are you saying BULK copy
will
>> not have the same LOG filling up problems?
>>
>>--Original Message--
>>"Don" <anonymous@.discussions.microsoft.com> wrote in
>> message
>>news:5f6d01c4c820$966b9c80$a301280a@.phx.gbl...
>> SQL 7.0
>> Trying to copy a table to a table with different
schema
>> and getting an error.
>> Old Schema example
>> Name, char, 30 NOT NULL
>> address, char, 30 NOT NULL
>> New Schema
>> Name,char, 30 NOT NULL
>> id,number,10 NULL ..........new field
>> address, char, 30 NOT NULL
>> I had imagined that the fields that were common would
>> copy and the new field "ID" would not fill in. I'm
>> pretty
>> sure my test worked yesterday, but today, it fails
with
>> the error that old.address is trying to copy to
>> new.number and it fails.
>> There are roughly 100 million rows and if I try to
>> modify
>> the old table directly by adding the ID field, SQL
>> eventually gives some kind of LOG error.
>> Any suggestions on how to convert this table to the
new
>> schema?
>> Thanks,
>> Don
>
>It depends on how you do the package.
>DTS (if you look closely) will use BCP in a lot of cases.
>Take a look at "Logged Bulk Copy" in the BOL. It
should show you how to do
>a minimally logged BCP command. BULK INSERT is
generally faster however, so
>keep that option in mind as well.
>HTH
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
>

Copying data between database tables

Hi. I need to move data from one database table to

another across database instances. A simple example of the typical

move would be:

[CODE]

INSERT into destination_db.dbo.table1

SELECT column1, column2, column3, column4 from source_db.dbo.table2

[/CODE]

My options are:

1. Create an SSIS package to perform the move.

2. Create sprocs and schedule the data move as jobs.

3. Write .NET code using sprocs to perform the move.

I'll have to move hundreds of thousands of records, so I want the

option that provides the best performance. I'm guessing that option 3

will be the slowest.

Thanks for the help!
To tell you the truth, you could just try it and find out which runs faster. We are probably talking seconds here at the 100,000 records level. One thing you might want to look into is partitions. If the table you are pulling to and from are identical then the switch option of the partion method with tables makes this happen in a second regardless of the number of records. It is just swapping data pages.|||

BSHOE wrote:

To tell you the truth, you could just try it and find out which runs faster. We are probably talking seconds here at the 100,000 records level. One thing you might want to look into is partitions. If the table you are pulling to and from are identical then the switch option of the partion method with tables makes this happen in a second regardless of the number of records. It is just swapping data pages.

BSHOE,

That won't work if the tables are on different instances. Which in this case they are.

To the original poster - if pure performance is your consideration then SSIS is the way to go.

-Jamie

|||

Jamie Thomson wrote:

BSHOE wrote:

To tell you the truth, you could just try it and find out which runs faster. We are probably talking seconds here at the 100,000 records level. One thing you might want to look into is partitions. If the table you are pulling to and from are identical then the switch option of the partion method with tables makes this happen in a second regardless of the number of records. It is just swapping data pages.

BSHOE,

That won't work if the tables are on different instances. Which in this case they are.

To the original poster - if pure performance is your consideration then SSIS is the way to go.

-Jamie

I concur with Jamie. Write a simple SSIS job to extract and then load the data. I can pull 100,000 records a second from SQL Server 2005 on my laptop into a flat file. Look on my website for details on how I do this and just substitute a table for the flat file in my demo.

Copy Schema

Hi,

What do I need to do in order to make a copy of a schema. For example lets say my database has 3 schemas - Test, Production and Staging. I want to make an exact copy of Production. ie. complete copy - all objects - tables, views, stored procs and also all the data and probably call it Production-New. Now we have 4 schemas in the database.

This needs to be initiated from the app that the user is currently using. Is there any built in support (TSQL functions/commands/Sps ?) for such an activity ? and if not what may be the direction that I need to look at to take this further ?

Overall I'm looking at being able to take a quick snapshot of a schema and start using that. I must mention that the volume of data will be substancial and the solution devised should be able to do it rather quickly - The user clicks a button in order to take a snap shot. So the wait time has to be reasonable.

Any suggestions/ideas will be great.

Thanks -

Avinash

If you mean an exact copy, then I just do a backup and restore. You can write a batch file to do this pretty easily. Write a backup stored script and a drop database/restore script and execute them with SQLCMD (or OSQL/ISQL for earlier versions)

The reason I suggest using a batch file is that you can run it as a user that has file system rights to the two databases and integrated security to make a copy to a different server.

For more elaborate schemes where you only want part of the data, then SSIS/DTS would be the way to go, but backup/restore is very straightforward.

|||

Many thanks MS Louis Davidson for your response.

Will try out SSIS.

Thanks and Regards,

Avinash