When working in DTS, specifically in the Transform Data Properties window,
when I click on the drop-down in the Table/View field the path will only
extend for the width of the field, even if the path name is too long to fit
in that field. As a result, I often can't see the full path displayed.
Thanks.JKKUS wrote:
> When working in DTS, specifically in the Transform Data Properties window,
> when I click on the drop-down in the Table/View field the path will only
> extend for the width of the field, even if the path name is too long to fi
t
> in that field. As a result, I often can't see the full path displayed.
> Thanks.
Hi,
Is it possible to place the cursor in the field and then use the 'End'
and 'Home' buttons to navigate?
James|||No, that will only scroll vertically up and down the drop-down list, but not
horizontally.
"James Wilson" wrote:
> JKKUS wrote:
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>|||This did not yet resolve my issue.
"James Wilson" wrote:
> JKKUS wrote:
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>sql
Showing posts with label dts. Show all posts
Showing posts with label dts. Show all posts
Thursday, March 22, 2012
Drop-down in DTS Package cut off
When working in DTS, specifically in the Transform Data Properties window,
when I click on the drop-down in the Table/View field the path will only
extend for the width of the field, even if the path name is too long to fit
in that field. As a result, I often can't see the full path displayed.
Thanks.JKKUS wrote:
> When working in DTS, specifically in the Transform Data Properties window,
> when I click on the drop-down in the Table/View field the path will only
> extend for the width of the field, even if the path name is too long to fit
> in that field. As a result, I often can't see the full path displayed.
> Thanks.
Hi,
Is it possible to place the cursor in the field and then use the 'End'
and 'Home' buttons to navigate?
James|||No, that will only scroll vertically up and down the drop-down list, but not
horizontally.
"James Wilson" wrote:
> JKKUS wrote:
> > When working in DTS, specifically in the Transform Data Properties window,
> > when I click on the drop-down in the Table/View field the path will only
> > extend for the width of the field, even if the path name is too long to fit
> > in that field. As a result, I often can't see the full path displayed.
> >
> > Thanks.
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>|||This did not yet resolve my issue.
"James Wilson" wrote:
> JKKUS wrote:
> > When working in DTS, specifically in the Transform Data Properties window,
> > when I click on the drop-down in the Table/View field the path will only
> > extend for the width of the field, even if the path name is too long to fit
> > in that field. As a result, I often can't see the full path displayed.
> >
> > Thanks.
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>
when I click on the drop-down in the Table/View field the path will only
extend for the width of the field, even if the path name is too long to fit
in that field. As a result, I often can't see the full path displayed.
Thanks.JKKUS wrote:
> When working in DTS, specifically in the Transform Data Properties window,
> when I click on the drop-down in the Table/View field the path will only
> extend for the width of the field, even if the path name is too long to fit
> in that field. As a result, I often can't see the full path displayed.
> Thanks.
Hi,
Is it possible to place the cursor in the field and then use the 'End'
and 'Home' buttons to navigate?
James|||No, that will only scroll vertically up and down the drop-down list, but not
horizontally.
"James Wilson" wrote:
> JKKUS wrote:
> > When working in DTS, specifically in the Transform Data Properties window,
> > when I click on the drop-down in the Table/View field the path will only
> > extend for the width of the field, even if the path name is too long to fit
> > in that field. As a result, I often can't see the full path displayed.
> >
> > Thanks.
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>|||This did not yet resolve my issue.
"James Wilson" wrote:
> JKKUS wrote:
> > When working in DTS, specifically in the Transform Data Properties window,
> > when I click on the drop-down in the Table/View field the path will only
> > extend for the width of the field, even if the path name is too long to fit
> > in that field. As a result, I often can't see the full path displayed.
> >
> > Thanks.
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>
Drop-down in DTS Package cut off
When working in DTS, specifically in the Transform Data Properties window,
when I click on the drop-down in the Table/View field the path will only
extend for the width of the field, even if the path name is too long to fit
in that field. As a result, I often can't see the full path displayed.
Thanks.
JKKUS wrote:
> When working in DTS, specifically in the Transform Data Properties window,
> when I click on the drop-down in the Table/View field the path will only
> extend for the width of the field, even if the path name is too long to fit
> in that field. As a result, I often can't see the full path displayed.
> Thanks.
Hi,
Is it possible to place the cursor in the field and then use the 'End'
and 'Home' buttons to navigate?
James
|||No, that will only scroll vertically up and down the drop-down list, but not
horizontally.
"James Wilson" wrote:
> JKKUS wrote:
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>
|||This did not yet resolve my issue.
"James Wilson" wrote:
> JKKUS wrote:
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>
when I click on the drop-down in the Table/View field the path will only
extend for the width of the field, even if the path name is too long to fit
in that field. As a result, I often can't see the full path displayed.
Thanks.
JKKUS wrote:
> When working in DTS, specifically in the Transform Data Properties window,
> when I click on the drop-down in the Table/View field the path will only
> extend for the width of the field, even if the path name is too long to fit
> in that field. As a result, I often can't see the full path displayed.
> Thanks.
Hi,
Is it possible to place the cursor in the field and then use the 'End'
and 'Home' buttons to navigate?
James
|||No, that will only scroll vertically up and down the drop-down list, but not
horizontally.
"James Wilson" wrote:
> JKKUS wrote:
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>
|||This did not yet resolve my issue.
"James Wilson" wrote:
> JKKUS wrote:
> Hi,
> Is it possible to place the cursor in the field and then use the 'End'
> and 'Home' buttons to navigate?
> James
>
Wednesday, March 21, 2012
Drop the table or Truncate?
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.
They are effectively the same, but dropping the table in the right order is
effectively quicker.
Anyway, you could really gain some performance, if you could look into the
possibility of incremental updates, instead of getting rid of the whole lot
and repopulating.
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:4092B4F1.6060700@.deltanet.com...
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.
|||Narayana Vyas Kondreddi wrote:
> They are effectively the same, but dropping the table in the right order is
> effectively quicker.
I thought so, also. But someone had mentioned that tables are meant to
be permanent, so it would be better to truncate. The problem is just
because they are meant to be permanent, doesn't mean there is a problem
doing it.
Someone else said it would be better to do all the table drops and
creates - then populate them. I'm not sure why that would be better.
Why would dropping them in the correct order be quicker - I assume you
are talking about referential integrity. In my case, I am deleting
everything each time at night.
> Anyway, you could really gain some performance, if you could look into the
> possibility of incremental updates, instead of getting rid of the whole lot
> and repopulating.
I agree. But in our case the tables are already created on a foreign
system and we have no control over the schema, so it would be difficult
to do incremental updates.
Thanks,
Tom.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
> Is .NET important for a database professional?
> http://vyaskn.tripod.com/poll.htm
>
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:4092B4F1.6060700@.deltanet.com...
> I am setting up about 60 or so DTS packages to run every night. These
> packages will be recreating all the tables from a foreign database.
> At the moment, I have them dropping the tables, creating the tables,
> copying all the data to the new table and creating the keys.
> Would it be better to just drop the keys, truncate the tables, copy the
> data and recreate the keys? Or does it really matter? I am, in
> essence, doing the same thing.
> Just trying to see if I am going about the task in the best way.
> Thanks,
> Tom.
>
>
|||Thomas
As Vyas said that dropping the table in the right order is
effectively quicker.
I would a little bit re-phrase his by saying that truncating the table in
the right order is effectively quicker.
As I understood you don't have to drop the table so you have to know
relationship between them and to define the order to truncate tables.( First
truncate a referenced(child) table and then a referncing(father) )
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:40936865.4010204@.deltanet.com...[vbcol=seagreen]
> Narayana Vyas Kondreddi wrote:
is[vbcol=seagreen]
>
> I thought so, also. But someone had mentioned that tables are meant to
> be permanent, so it would be better to truncate. The problem is just
> because they are meant to be permanent, doesn't mean there is a problem
> doing it.
> Someone else said it would be better to do all the table drops and
> creates - then populate them. I'm not sure why that would be better.
> Why would dropping them in the correct order be quicker - I assume you
> are talking about referential integrity. In my case, I am deleting
> everything each time at night.
the[vbcol=seagreen]
lot
>
> I agree. But in our case the tables are already created on a foreign
> system and we have no control over the schema, so it would be difficult
> to do incremental updates.
> Thanks,
> Tom.
>
|||Uri Dimant wrote:
> Thomas
> As Vyas said that dropping the table in the right order is
> effectively quicker.
> I would a little bit re-phrase his by saying that truncating the table in
> the right order is effectively quicker.
> As I understood you don't have to drop the table so you have to know
> relationship between them and to define the order to truncate tables.( First
> truncate a referenced(child) table and then a referncing(father) )
I am running this using DTS and to do a straight copy, the program does
a "Create" with optional "Drop". I was thinking of doing a
"Select/Into". So I would do a "Drop Table" and then do a "Select/Into"
from the foreign database.
Is there a reason why I should use the Create and Insert that DTS does
vs the Select/Into way. I was thinking of doing this so I wouldn't have
to make 60 packages (one for each file copied), since each create would
be different. I would just need to pass the file name in a Global
Variable and let DTS do the Select/Into. This would allow me to create
only one package.
Of course, the other problem would be creating the indexes after the
Select/Into. If I need to have a package for each table just to handle
the Indexes, I might as well let DTS do it's normal Create.
Thanks,
Tom.
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:40936865.4010204@.deltanet.com...
> is
> the
> lot
>
>
|||One thing to consider;
Truncating the table does not get logged in the transaction log. So if
there is a lot of data in the tables, deleting the tables can cause the log
to grow.
Rand
This posting is provided "as is" with no warranties and confers no rights.
sql
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.
They are effectively the same, but dropping the table in the right order is
effectively quicker.
Anyway, you could really gain some performance, if you could look into the
possibility of incremental updates, instead of getting rid of the whole lot
and repopulating.
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:4092B4F1.6060700@.deltanet.com...
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.
|||Narayana Vyas Kondreddi wrote:
> They are effectively the same, but dropping the table in the right order is
> effectively quicker.
I thought so, also. But someone had mentioned that tables are meant to
be permanent, so it would be better to truncate. The problem is just
because they are meant to be permanent, doesn't mean there is a problem
doing it.
Someone else said it would be better to do all the table drops and
creates - then populate them. I'm not sure why that would be better.
Why would dropping them in the correct order be quicker - I assume you
are talking about referential integrity. In my case, I am deleting
everything each time at night.
> Anyway, you could really gain some performance, if you could look into the
> possibility of incremental updates, instead of getting rid of the whole lot
> and repopulating.
I agree. But in our case the tables are already created on a foreign
system and we have no control over the schema, so it would be difficult
to do incremental updates.
Thanks,
Tom.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
> Is .NET important for a database professional?
> http://vyaskn.tripod.com/poll.htm
>
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:4092B4F1.6060700@.deltanet.com...
> I am setting up about 60 or so DTS packages to run every night. These
> packages will be recreating all the tables from a foreign database.
> At the moment, I have them dropping the tables, creating the tables,
> copying all the data to the new table and creating the keys.
> Would it be better to just drop the keys, truncate the tables, copy the
> data and recreate the keys? Or does it really matter? I am, in
> essence, doing the same thing.
> Just trying to see if I am going about the task in the best way.
> Thanks,
> Tom.
>
>
|||Thomas
As Vyas said that dropping the table in the right order is
effectively quicker.
I would a little bit re-phrase his by saying that truncating the table in
the right order is effectively quicker.
As I understood you don't have to drop the table so you have to know
relationship between them and to define the order to truncate tables.( First
truncate a referenced(child) table and then a referncing(father) )
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:40936865.4010204@.deltanet.com...[vbcol=seagreen]
> Narayana Vyas Kondreddi wrote:
is[vbcol=seagreen]
>
> I thought so, also. But someone had mentioned that tables are meant to
> be permanent, so it would be better to truncate. The problem is just
> because they are meant to be permanent, doesn't mean there is a problem
> doing it.
> Someone else said it would be better to do all the table drops and
> creates - then populate them. I'm not sure why that would be better.
> Why would dropping them in the correct order be quicker - I assume you
> are talking about referential integrity. In my case, I am deleting
> everything each time at night.
the[vbcol=seagreen]
lot
>
> I agree. But in our case the tables are already created on a foreign
> system and we have no control over the schema, so it would be difficult
> to do incremental updates.
> Thanks,
> Tom.
>
|||Uri Dimant wrote:
> Thomas
> As Vyas said that dropping the table in the right order is
> effectively quicker.
> I would a little bit re-phrase his by saying that truncating the table in
> the right order is effectively quicker.
> As I understood you don't have to drop the table so you have to know
> relationship between them and to define the order to truncate tables.( First
> truncate a referenced(child) table and then a referncing(father) )
I am running this using DTS and to do a straight copy, the program does
a "Create" with optional "Drop". I was thinking of doing a
"Select/Into". So I would do a "Drop Table" and then do a "Select/Into"
from the foreign database.
Is there a reason why I should use the Create and Insert that DTS does
vs the Select/Into way. I was thinking of doing this so I wouldn't have
to make 60 packages (one for each file copied), since each create would
be different. I would just need to pass the file name in a Global
Variable and let DTS do the Select/Into. This would allow me to create
only one package.
Of course, the other problem would be creating the indexes after the
Select/Into. If I need to have a package for each table just to handle
the Indexes, I might as well let DTS do it's normal Create.
Thanks,
Tom.
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:40936865.4010204@.deltanet.com...
> is
> the
> lot
>
>
|||One thing to consider;
Truncating the table does not get logged in the transaction log. So if
there is a lot of data in the tables, deleting the tables can cause the log
to grow.
Rand
This posting is provided "as is" with no warranties and confers no rights.
sql
Drop the table or Truncate?
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.They are effectively the same, but dropping the table in the right order is
effectively quicker.
Anyway, you could really gain some performance, if you could look into the
possibility of incremental updates, instead of getting rid of the whole lot
and repopulating.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:4092B4F1.6060700@.deltanet.com...
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.|||Narayana Vyas Kondreddi wrote:
> They are effectively the same, but dropping the table in the right order i
s
> effectively quicker.
I thought so, also. But someone had mentioned that tables are meant to
be permanent, so it would be better to truncate. The problem is just
because they are meant to be permanent, doesn't mean there is a problem
doing it.
Someone else said it would be better to do all the table drops and
creates - then populate them. I'm not sure why that would be better.
Why would dropping them in the correct order be quicker - I assume you
are talking about referential integrity. In my case, I am deleting
everything each time at night.
> Anyway, you could really gain some performance, if you could look into the
> possibility of incremental updates, instead of getting rid of the whole lo
t
> and repopulating.
I agree. But in our case the tables are already created on a foreign
system and we have no control over the schema, so it would be difficult
to do incremental updates.
Thanks,
Tom.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
> Is .NET important for a database professional?
> http://vyaskn.tripod.com/poll.htm
>
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:4092B4F1.6060700@.deltanet.com...
> I am setting up about 60 or so DTS packages to run every night. These
> packages will be recreating all the tables from a foreign database.
> At the moment, I have them dropping the tables, creating the tables,
> copying all the data to the new table and creating the keys.
> Would it be better to just drop the keys, truncate the tables, copy the
> data and recreate the keys? Or does it really matter? I am, in
> essence, doing the same thing.
> Just trying to see if I am going about the task in the best way.
> Thanks,
> Tom.
>
>|||Thomas
As Vyas said that dropping the table in the right order is
effectively quicker.
I would a little bit re-phrase his by saying that truncating the table in
the right order is effectively quicker.
As I understood you don't have to drop the table so you have to know
relationship between them and to define the order to truncate tables.( First
truncate a referenced(child) table and then a referncing(father) )
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:40936865.4010204@.deltanet.com...
> Narayana Vyas Kondreddi wrote:
>
is[vbcol=seagreen]
>
> I thought so, also. But someone had mentioned that tables are meant to
> be permanent, so it would be better to truncate. The problem is just
> because they are meant to be permanent, doesn't mean there is a problem
> doing it.
> Someone else said it would be better to do all the table drops and
> creates - then populate them. I'm not sure why that would be better.
> Why would dropping them in the correct order be quicker - I assume you
> are talking about referential integrity. In my case, I am deleting
> everything each time at night.
>
the[vbcol=seagreen]
lot[vbcol=seagreen]
>
> I agree. But in our case the tables are already created on a foreign
> system and we have no control over the schema, so it would be difficult
> to do incremental updates.
> Thanks,
> Tom.
>
>|||Uri Dimant wrote:
> Thomas
> As Vyas said that dropping the table in the right order is
> effectively quicker.
> I would a little bit re-phrase his by saying that truncating the table in
> the right order is effectively quicker.
> As I understood you don't have to drop the table so you have to know
> relationship between them and to define the order to truncate tables.( Fir
st
> truncate a referenced(child) table and then a referncing(father) )
I am running this using DTS and to do a straight copy, the program does
a "Create" with optional "Drop". I was thinking of doing a
"Select/Into". So I would do a "Drop Table" and then do a "Select/Into"
from the foreign database.
Is there a reason why I should use the Create and Insert that DTS does
vs the Select/Into way. I was thinking of doing this so I wouldn't have
to make 60 packages (one for each file copied), since each create would
be different. I would just need to pass the file name in a Global
Variable and let DTS do the Select/Into. This would allow me to create
only one package.
Of course, the other problem would be creating the indexes after the
Select/Into. If I need to have a package for each table just to handle
the Indexes, I might as well let DTS do it's normal Create.
Thanks,
Tom.
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:40936865.4010204@.deltanet.com...
>
> is
>
> the
>
> lot
>
>|||One thing to consider;
Truncating the table does not get logged in the transaction log. So if
there is a lot of data in the tables, deleting the tables can cause the log
to grow.
Rand
This posting is provided "as is" with no warranties and confers no rights.
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.They are effectively the same, but dropping the table in the right order is
effectively quicker.
Anyway, you could really gain some performance, if you could look into the
possibility of incremental updates, instead of getting rid of the whole lot
and repopulating.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:4092B4F1.6060700@.deltanet.com...
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.|||Narayana Vyas Kondreddi wrote:
> They are effectively the same, but dropping the table in the right order i
s
> effectively quicker.
I thought so, also. But someone had mentioned that tables are meant to
be permanent, so it would be better to truncate. The problem is just
because they are meant to be permanent, doesn't mean there is a problem
doing it.
Someone else said it would be better to do all the table drops and
creates - then populate them. I'm not sure why that would be better.
Why would dropping them in the correct order be quicker - I assume you
are talking about referential integrity. In my case, I am deleting
everything each time at night.
> Anyway, you could really gain some performance, if you could look into the
> possibility of incremental updates, instead of getting rid of the whole lo
t
> and repopulating.
I agree. But in our case the tables are already created on a foreign
system and we have no control over the schema, so it would be difficult
to do incremental updates.
Thanks,
Tom.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
> Is .NET important for a database professional?
> http://vyaskn.tripod.com/poll.htm
>
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:4092B4F1.6060700@.deltanet.com...
> I am setting up about 60 or so DTS packages to run every night. These
> packages will be recreating all the tables from a foreign database.
> At the moment, I have them dropping the tables, creating the tables,
> copying all the data to the new table and creating the keys.
> Would it be better to just drop the keys, truncate the tables, copy the
> data and recreate the keys? Or does it really matter? I am, in
> essence, doing the same thing.
> Just trying to see if I am going about the task in the best way.
> Thanks,
> Tom.
>
>|||Thomas
As Vyas said that dropping the table in the right order is
effectively quicker.
I would a little bit re-phrase his by saying that truncating the table in
the right order is effectively quicker.
As I understood you don't have to drop the table so you have to know
relationship between them and to define the order to truncate tables.( First
truncate a referenced(child) table and then a referncing(father) )
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:40936865.4010204@.deltanet.com...
> Narayana Vyas Kondreddi wrote:
>
is[vbcol=seagreen]
>
> I thought so, also. But someone had mentioned that tables are meant to
> be permanent, so it would be better to truncate. The problem is just
> because they are meant to be permanent, doesn't mean there is a problem
> doing it.
> Someone else said it would be better to do all the table drops and
> creates - then populate them. I'm not sure why that would be better.
> Why would dropping them in the correct order be quicker - I assume you
> are talking about referential integrity. In my case, I am deleting
> everything each time at night.
>
the[vbcol=seagreen]
lot[vbcol=seagreen]
>
> I agree. But in our case the tables are already created on a foreign
> system and we have no control over the schema, so it would be difficult
> to do incremental updates.
> Thanks,
> Tom.
>
>|||Uri Dimant wrote:
> Thomas
> As Vyas said that dropping the table in the right order is
> effectively quicker.
> I would a little bit re-phrase his by saying that truncating the table in
> the right order is effectively quicker.
> As I understood you don't have to drop the table so you have to know
> relationship between them and to define the order to truncate tables.( Fir
st
> truncate a referenced(child) table and then a referncing(father) )
I am running this using DTS and to do a straight copy, the program does
a "Create" with optional "Drop". I was thinking of doing a
"Select/Into". So I would do a "Drop Table" and then do a "Select/Into"
from the foreign database.
Is there a reason why I should use the Create and Insert that DTS does
vs the Select/Into way. I was thinking of doing this so I wouldn't have
to make 60 packages (one for each file copied), since each create would
be different. I would just need to pass the file name in a Global
Variable and let DTS do the Select/Into. This would allow me to create
only one package.
Of course, the other problem would be creating the indexes after the
Select/Into. If I need to have a package for each table just to handle
the Indexes, I might as well let DTS do it's normal Create.
Thanks,
Tom.
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:40936865.4010204@.deltanet.com...
>
> is
>
> the
>
> lot
>
>|||One thing to consider;
Truncating the table does not get logged in the transaction log. So if
there is a lot of data in the tables, deleting the tables can cause the log
to grow.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Drop the table or Truncate?
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.They are effectively the same, but dropping the table in the right order is
effectively quicker.
Anyway, you could really gain some performance, if you could look into the
possibility of incremental updates, instead of getting rid of the whole lot
and repopulating.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:4092B4F1.6060700@.deltanet.com...
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.|||Narayana Vyas Kondreddi wrote:
> They are effectively the same, but dropping the table in the right order is
> effectively quicker.
I thought so, also. But someone had mentioned that tables are meant to
be permanent, so it would be better to truncate. The problem is just
because they are meant to be permanent, doesn't mean there is a problem
doing it.
Someone else said it would be better to do all the table drops and
creates - then populate them. I'm not sure why that would be better.
Why would dropping them in the correct order be quicker - I assume you
are talking about referential integrity. In my case, I am deleting
everything each time at night.
> Anyway, you could really gain some performance, if you could look into the
> possibility of incremental updates, instead of getting rid of the whole lot
> and repopulating.
I agree. But in our case the tables are already created on a foreign
system and we have no control over the schema, so it would be difficult
to do incremental updates.
Thanks,
Tom.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
> Is .NET important for a database professional?
> http://vyaskn.tripod.com/poll.htm
>
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:4092B4F1.6060700@.deltanet.com...
> I am setting up about 60 or so DTS packages to run every night. These
> packages will be recreating all the tables from a foreign database.
> At the moment, I have them dropping the tables, creating the tables,
> copying all the data to the new table and creating the keys.
> Would it be better to just drop the keys, truncate the tables, copy the
> data and recreate the keys? Or does it really matter? I am, in
> essence, doing the same thing.
> Just trying to see if I am going about the task in the best way.
> Thanks,
> Tom.
>
>|||Thomas
As Vyas said that dropping the table in the right order is
effectively quicker.
I would a little bit re-phrase his by saying that truncating the table in
the right order is effectively quicker.
As I understood you don't have to drop the table so you have to know
relationship between them and to define the order to truncate tables.( First
truncate a referenced(child) table and then a referncing(father) )
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:40936865.4010204@.deltanet.com...
> Narayana Vyas Kondreddi wrote:
> > They are effectively the same, but dropping the table in the right order
is
> > effectively quicker.
>
> I thought so, also. But someone had mentioned that tables are meant to
> be permanent, so it would be better to truncate. The problem is just
> because they are meant to be permanent, doesn't mean there is a problem
> doing it.
> Someone else said it would be better to do all the table drops and
> creates - then populate them. I'm not sure why that would be better.
> Why would dropping them in the correct order be quicker - I assume you
> are talking about referential integrity. In my case, I am deleting
> everything each time at night.
> >
> > Anyway, you could really gain some performance, if you could look into
the
> > possibility of incremental updates, instead of getting rid of the whole
lot
> > and repopulating.
>
> I agree. But in our case the tables are already created on a foreign
> system and we have no control over the schema, so it would be difficult
> to do incremental updates.
> Thanks,
> Tom.
> > --
> > HTH,
> > Vyas, MVP (SQL Server)
> > http://vyaskn.tripod.com/
> > Is .NET important for a database professional?
> > http://vyaskn.tripod.com/poll.htm
> >
> >
> >
> >
> > "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> > news:4092B4F1.6060700@.deltanet.com...
> > I am setting up about 60 or so DTS packages to run every night. These
> > packages will be recreating all the tables from a foreign database.
> >
> > At the moment, I have them dropping the tables, creating the tables,
> > copying all the data to the new table and creating the keys.
> >
> > Would it be better to just drop the keys, truncate the tables, copy the
> > data and recreate the keys? Or does it really matter? I am, in
> > essence, doing the same thing.
> >
> > Just trying to see if I am going about the task in the best way.
> >
> > Thanks,
> >
> > Tom.
> >
> >
> >
> >
>|||Uri Dimant wrote:
> Thomas
> As Vyas said that dropping the table in the right order is
> effectively quicker.
> I would a little bit re-phrase his by saying that truncating the table in
> the right order is effectively quicker.
> As I understood you don't have to drop the table so you have to know
> relationship between them and to define the order to truncate tables.( First
> truncate a referenced(child) table and then a referncing(father) )
I am running this using DTS and to do a straight copy, the program does
a "Create" with optional "Drop". I was thinking of doing a
"Select/Into". So I would do a "Drop Table" and then do a "Select/Into"
from the foreign database.
Is there a reason why I should use the Create and Insert that DTS does
vs the Select/Into way. I was thinking of doing this so I wouldn't have
to make 60 packages (one for each file copied), since each create would
be different. I would just need to pass the file name in a Global
Variable and let DTS do the Select/Into. This would allow me to create
only one package.
Of course, the other problem would be creating the indexes after the
Select/Into. If I need to have a package for each table just to handle
the Indexes, I might as well let DTS do it's normal Create.
Thanks,
Tom.
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:40936865.4010204@.deltanet.com...
>>Narayana Vyas Kondreddi wrote:
>>
>>They are effectively the same, but dropping the table in the right order
> is
>>effectively quicker.
>>
>>I thought so, also. But someone had mentioned that tables are meant to
>>be permanent, so it would be better to truncate. The problem is just
>>because they are meant to be permanent, doesn't mean there is a problem
>>doing it.
>>Someone else said it would be better to do all the table drops and
>>creates - then populate them. I'm not sure why that would be better.
>>Why would dropping them in the correct order be quicker - I assume you
>>are talking about referential integrity. In my case, I am deleting
>>everything each time at night.
>>
>>Anyway, you could really gain some performance, if you could look into
> the
>>possibility of incremental updates, instead of getting rid of the whole
> lot
>>and repopulating.
>>
>>I agree. But in our case the tables are already created on a foreign
>>system and we have no control over the schema, so it would be difficult
>>to do incremental updates.
>>Thanks,
>>Tom.
>>
>>--
>>HTH,
>>Vyas, MVP (SQL Server)
>>http://vyaskn.tripod.com/
>>Is .NET important for a database professional?
>>http://vyaskn.tripod.com/poll.htm
>>
>>
>>"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
>>news:4092B4F1.6060700@.deltanet.com...
>>I am setting up about 60 or so DTS packages to run every night. These
>>packages will be recreating all the tables from a foreign database.
>>At the moment, I have them dropping the tables, creating the tables,
>>copying all the data to the new table and creating the keys.
>>Would it be better to just drop the keys, truncate the tables, copy the
>>data and recreate the keys? Or does it really matter? I am, in
>>essence, doing the same thing.
>>Just trying to see if I am going about the task in the best way.
>>Thanks,
>>Tom.
>>
>>
>|||One thing to consider;
Truncating the table does not get logged in the transaction log. So if
there is a lot of data in the tables, deleting the tables can cause the log
to grow.
Rand
This posting is provided "as is" with no warranties and confers no rights.
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.They are effectively the same, but dropping the table in the right order is
effectively quicker.
Anyway, you could really gain some performance, if you could look into the
possibility of incremental updates, instead of getting rid of the whole lot
and repopulating.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:4092B4F1.6060700@.deltanet.com...
I am setting up about 60 or so DTS packages to run every night. These
packages will be recreating all the tables from a foreign database.
At the moment, I have them dropping the tables, creating the tables,
copying all the data to the new table and creating the keys.
Would it be better to just drop the keys, truncate the tables, copy the
data and recreate the keys? Or does it really matter? I am, in
essence, doing the same thing.
Just trying to see if I am going about the task in the best way.
Thanks,
Tom.|||Narayana Vyas Kondreddi wrote:
> They are effectively the same, but dropping the table in the right order is
> effectively quicker.
I thought so, also. But someone had mentioned that tables are meant to
be permanent, so it would be better to truncate. The problem is just
because they are meant to be permanent, doesn't mean there is a problem
doing it.
Someone else said it would be better to do all the table drops and
creates - then populate them. I'm not sure why that would be better.
Why would dropping them in the correct order be quicker - I assume you
are talking about referential integrity. In my case, I am deleting
everything each time at night.
> Anyway, you could really gain some performance, if you could look into the
> possibility of incremental updates, instead of getting rid of the whole lot
> and repopulating.
I agree. But in our case the tables are already created on a foreign
system and we have no control over the schema, so it would be difficult
to do incremental updates.
Thanks,
Tom.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
> Is .NET important for a database professional?
> http://vyaskn.tripod.com/poll.htm
>
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:4092B4F1.6060700@.deltanet.com...
> I am setting up about 60 or so DTS packages to run every night. These
> packages will be recreating all the tables from a foreign database.
> At the moment, I have them dropping the tables, creating the tables,
> copying all the data to the new table and creating the keys.
> Would it be better to just drop the keys, truncate the tables, copy the
> data and recreate the keys? Or does it really matter? I am, in
> essence, doing the same thing.
> Just trying to see if I am going about the task in the best way.
> Thanks,
> Tom.
>
>|||Thomas
As Vyas said that dropping the table in the right order is
effectively quicker.
I would a little bit re-phrase his by saying that truncating the table in
the right order is effectively quicker.
As I understood you don't have to drop the table so you have to know
relationship between them and to define the order to truncate tables.( First
truncate a referenced(child) table and then a referncing(father) )
"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
news:40936865.4010204@.deltanet.com...
> Narayana Vyas Kondreddi wrote:
> > They are effectively the same, but dropping the table in the right order
is
> > effectively quicker.
>
> I thought so, also. But someone had mentioned that tables are meant to
> be permanent, so it would be better to truncate. The problem is just
> because they are meant to be permanent, doesn't mean there is a problem
> doing it.
> Someone else said it would be better to do all the table drops and
> creates - then populate them. I'm not sure why that would be better.
> Why would dropping them in the correct order be quicker - I assume you
> are talking about referential integrity. In my case, I am deleting
> everything each time at night.
> >
> > Anyway, you could really gain some performance, if you could look into
the
> > possibility of incremental updates, instead of getting rid of the whole
lot
> > and repopulating.
>
> I agree. But in our case the tables are already created on a foreign
> system and we have no control over the schema, so it would be difficult
> to do incremental updates.
> Thanks,
> Tom.
> > --
> > HTH,
> > Vyas, MVP (SQL Server)
> > http://vyaskn.tripod.com/
> > Is .NET important for a database professional?
> > http://vyaskn.tripod.com/poll.htm
> >
> >
> >
> >
> > "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> > news:4092B4F1.6060700@.deltanet.com...
> > I am setting up about 60 or so DTS packages to run every night. These
> > packages will be recreating all the tables from a foreign database.
> >
> > At the moment, I have them dropping the tables, creating the tables,
> > copying all the data to the new table and creating the keys.
> >
> > Would it be better to just drop the keys, truncate the tables, copy the
> > data and recreate the keys? Or does it really matter? I am, in
> > essence, doing the same thing.
> >
> > Just trying to see if I am going about the task in the best way.
> >
> > Thanks,
> >
> > Tom.
> >
> >
> >
> >
>|||Uri Dimant wrote:
> Thomas
> As Vyas said that dropping the table in the right order is
> effectively quicker.
> I would a little bit re-phrase his by saying that truncating the table in
> the right order is effectively quicker.
> As I understood you don't have to drop the table so you have to know
> relationship between them and to define the order to truncate tables.( First
> truncate a referenced(child) table and then a referncing(father) )
I am running this using DTS and to do a straight copy, the program does
a "Create" with optional "Drop". I was thinking of doing a
"Select/Into". So I would do a "Drop Table" and then do a "Select/Into"
from the foreign database.
Is there a reason why I should use the Create and Insert that DTS does
vs the Select/Into way. I was thinking of doing this so I wouldn't have
to make 60 packages (one for each file copied), since each create would
be different. I would just need to pass the file name in a Global
Variable and let DTS do the Select/Into. This would allow me to create
only one package.
Of course, the other problem would be creating the indexes after the
Select/Into. If I need to have a package for each table just to handle
the Indexes, I might as well let DTS do it's normal Create.
Thanks,
Tom.
>
> "Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
> news:40936865.4010204@.deltanet.com...
>>Narayana Vyas Kondreddi wrote:
>>
>>They are effectively the same, but dropping the table in the right order
> is
>>effectively quicker.
>>
>>I thought so, also. But someone had mentioned that tables are meant to
>>be permanent, so it would be better to truncate. The problem is just
>>because they are meant to be permanent, doesn't mean there is a problem
>>doing it.
>>Someone else said it would be better to do all the table drops and
>>creates - then populate them. I'm not sure why that would be better.
>>Why would dropping them in the correct order be quicker - I assume you
>>are talking about referential integrity. In my case, I am deleting
>>everything each time at night.
>>
>>Anyway, you could really gain some performance, if you could look into
> the
>>possibility of incremental updates, instead of getting rid of the whole
> lot
>>and repopulating.
>>
>>I agree. But in our case the tables are already created on a foreign
>>system and we have no control over the schema, so it would be difficult
>>to do incremental updates.
>>Thanks,
>>Tom.
>>
>>--
>>HTH,
>>Vyas, MVP (SQL Server)
>>http://vyaskn.tripod.com/
>>Is .NET important for a database professional?
>>http://vyaskn.tripod.com/poll.htm
>>
>>
>>"Thomas Scheiderich" <tfs@.deltanet.com> wrote in message
>>news:4092B4F1.6060700@.deltanet.com...
>>I am setting up about 60 or so DTS packages to run every night. These
>>packages will be recreating all the tables from a foreign database.
>>At the moment, I have them dropping the tables, creating the tables,
>>copying all the data to the new table and creating the keys.
>>Would it be better to just drop the keys, truncate the tables, copy the
>>data and recreate the keys? Or does it really matter? I am, in
>>essence, doing the same thing.
>>Just trying to see if I am going about the task in the best way.
>>Thanks,
>>Tom.
>>
>>
>|||One thing to consider;
Truncating the table does not get logged in the transaction log. So if
there is a lot of data in the tables, deleting the tables can cause the log
to grow.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Drop The Create Table
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Either add an ExecSQL task to add the permissions or do the create AND the
GRANT both within the same ExecSQL task.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
..
"Darren" <jobs@.supre.au.com> wrote in message
news:%23lUe7vvDFHA.960@.TK2MSFTNGP09.phx.gbl...
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Either add an ExecSQL task to add the permissions or do the create AND the
GRANT both within the same ExecSQL task.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
..
"Darren" <jobs@.supre.au.com> wrote in message
news:%23lUe7vvDFHA.960@.TK2MSFTNGP09.phx.gbl...
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Drop The Create Table
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!Either add an ExecSQL task to add the permissions or do the create AND the
GRANT both within the same ExecSQL task.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
.
"Darren" <jobs@.supre.au.com> wrote in message
news:%23lUe7vvDFHA.960@.TK2MSFTNGP09.phx.gbl...
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!sql
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!Either add an ExecSQL task to add the permissions or do the create AND the
GRANT both within the same ExecSQL task.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
.
"Darren" <jobs@.supre.au.com> wrote in message
news:%23lUe7vvDFHA.960@.TK2MSFTNGP09.phx.gbl...
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!sql
Drop The Create Table
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!Either add an ExecSQL task to add the permissions or do the create AND the
GRANT both within the same ExecSQL task.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
.
"Darren" <jobs@.supre.au.com> wrote in message
news:%23lUe7vvDFHA.960@.TK2MSFTNGP09.phx.gbl...
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!Either add an ExecSQL task to add the permissions or do the create AND the
GRANT both within the same ExecSQL task.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
.
"Darren" <jobs@.supre.au.com> wrote in message
news:%23lUe7vvDFHA.960@.TK2MSFTNGP09.phx.gbl...
I have a DTS package which drops then creates a table before inserting
data from a csv.
My problem is each time I drop the create the table, I must reset the
permissions to the table. How can I automate this?
My current create table code is:
CREATE TABLE [DataFlex].[dbo].[stylemaster] (
[style] varchar (12) NOT NULL,
[retail] numeric (11,2) NULL,
[nzretail] numeric (10,2) NULL,
[descr] varchar (40) NOT NULL,
[colour] int NOT NULL,
[colourway] int NULL,
[season] varchar (10) NULL,
[maingroup] varchar (10) NULL,
[subgroup] varchar (9) NULL,
[story] varchar (9) NULL,
[ac7] varchar (1) NULL,
[fabric] varchar (12) NULL,
[imagename] varchar (30) NULL,
[units] int NULL,
[dollarmargin] numeric (10,2) NULL,
[onsale] char (1) NULL,
[active] varchar (1) NULL,
[fabgroup] varchar (9) NULL
)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Drop Table Gets skipped in a query batch
I have a situation in SQL Svr 2k that I can't explain. I have a query batch that runs in a SQL step in a DTS package. All steps execute except the Drop Table statements. Here is a section of the code;
************************************************** ****
INSERT INTO Oral_VitDhistory ( MeNumber, DrugType, Territory, Quantity, SalesAmt, DataType, RXDate )
SELECT tbl_Oral_VitDHistory.MENumber, tbl_Oral_VitDHistory.DrugType, tbl_Oral_VitDHistory.Territory, tbl_Oral_VitDHistory.Quantity, tbl_Oral_VitDHistory.SalesAmt, tbl_Oral_VitDHistory.DataType, tbl_Oral_VitDHistory.RXDate
FROM Data_Warehouse..tbl_Oral_VitDHistory WHERE tbl_Oral_VitDHistory.Territory Is Not Null
drop table Data_Warehouse..NDC24month_Cost
drop table Data_Warehouse..NDC24month_Count
/* Process New Rx */
select MeNumber, zip, RXTypecode, DrugTYpe, NRX1 into NDC24month_Cost from Data_Warehouse..NDC24month where RxTypecode = '$ B'
Insert into tbl_Oral_VitDHistory(MeNumber, DrugType, Quantity, SalesAmt) select a.MeNumber,
a.DrugType, a.NRX1 as Quantity, b.NRX1 as SalesAmt from Data_Warehouse..NDC24month_Count as a, NDC24month_Cost
as b where a.Menumber = b.MeNumber and a.DrugType = b.DrugType
************************************************** *******
The drop table statements appear to get skipped and the code fails because the column names should have been changed as the dropped tables should have been recreated with a different column name.
This used to work fine. Then suddenly it stopped working. No changes to the SQL installation from when it worked to when it stopped. The batch also fails in the QA if cut and pasted and ran from there.
I ran accross this once before in a Stored Proc with the Drop table statement and had to put the statement in a different procedure.
Anybody ever run accross this? I have searched the MS KB to no avail.
Thanks in advance to the genius who can help a guy out!Howdy,
I have come across this before - usually the best way to get around it is to break the code into separate sprocs & then call each in turn from a main sproc. Even using BEGIN TRAN...COMMIT TRAN wont help....it seems to get a bee in its bonnet and thats it......
Also, if its in DTS package etc , break up the code into logical chunks with end of batch "GO" commands. This will mean separate sprocs if you run it in one sproc currently.
Cheers,
SG.|||Thanks for your help!
Thats about where I thought I would have to go with it.
You confirmed my suspicions!
Have a great one!
Originally posted by sqlguy7777
Howdy,
I have come across this before - usually the best way to get around it is to break the code into separate sprocs & then call each in turn from a main sproc. Even using BEGIN TRAN...COMMIT TRAN wont help....it seems to get a bee in its bonnet and thats it......
Also, if its in DTS package etc , break up the code into logical chunks with end of batch "GO" commands. This will mean separate sprocs if you run it in one sproc currently.
Cheers,
SG.
************************************************** ****
INSERT INTO Oral_VitDhistory ( MeNumber, DrugType, Territory, Quantity, SalesAmt, DataType, RXDate )
SELECT tbl_Oral_VitDHistory.MENumber, tbl_Oral_VitDHistory.DrugType, tbl_Oral_VitDHistory.Territory, tbl_Oral_VitDHistory.Quantity, tbl_Oral_VitDHistory.SalesAmt, tbl_Oral_VitDHistory.DataType, tbl_Oral_VitDHistory.RXDate
FROM Data_Warehouse..tbl_Oral_VitDHistory WHERE tbl_Oral_VitDHistory.Territory Is Not Null
drop table Data_Warehouse..NDC24month_Cost
drop table Data_Warehouse..NDC24month_Count
/* Process New Rx */
select MeNumber, zip, RXTypecode, DrugTYpe, NRX1 into NDC24month_Cost from Data_Warehouse..NDC24month where RxTypecode = '$ B'
Insert into tbl_Oral_VitDHistory(MeNumber, DrugType, Quantity, SalesAmt) select a.MeNumber,
a.DrugType, a.NRX1 as Quantity, b.NRX1 as SalesAmt from Data_Warehouse..NDC24month_Count as a, NDC24month_Cost
as b where a.Menumber = b.MeNumber and a.DrugType = b.DrugType
************************************************** *******
The drop table statements appear to get skipped and the code fails because the column names should have been changed as the dropped tables should have been recreated with a different column name.
This used to work fine. Then suddenly it stopped working. No changes to the SQL installation from when it worked to when it stopped. The batch also fails in the QA if cut and pasted and ran from there.
I ran accross this once before in a Stored Proc with the Drop table statement and had to put the statement in a different procedure.
Anybody ever run accross this? I have searched the MS KB to no avail.
Thanks in advance to the genius who can help a guy out!Howdy,
I have come across this before - usually the best way to get around it is to break the code into separate sprocs & then call each in turn from a main sproc. Even using BEGIN TRAN...COMMIT TRAN wont help....it seems to get a bee in its bonnet and thats it......
Also, if its in DTS package etc , break up the code into logical chunks with end of batch "GO" commands. This will mean separate sprocs if you run it in one sproc currently.
Cheers,
SG.|||Thanks for your help!
Thats about where I thought I would have to go with it.
You confirmed my suspicions!
Have a great one!
Originally posted by sqlguy7777
Howdy,
I have come across this before - usually the best way to get around it is to break the code into separate sprocs & then call each in turn from a main sproc. Even using BEGIN TRAN...COMMIT TRAN wont help....it seems to get a bee in its bonnet and thats it......
Also, if its in DTS package etc , break up the code into logical chunks with end of batch "GO" commands. This will mean separate sprocs if you run it in one sproc currently.
Cheers,
SG.
Monday, March 19, 2012
Drop Stored Procedure causing Dropped Tables
Hey guys, has anyone ever seen this happen:
Try to move stored proc from one DB to another using DTS, errors on create proc. Create proc manually.
Three tables referenced by that stored proc have been dropped and re-created with the same table structure.
I'm not 100% certain that it happened at exactly the same time, but it seems to be around the same time. Any ideas? Anyone seen this happen before?You will have to check the options you picked for the Transfer task in your DTS package. Did you ask it to move dependent objects also? For more help on the DTS package/tasks, please post in the SQL Server Integration Services forum.|||It was selected for dependent objects, but those tables are not dependent on the stored proc. As far as I know, the DTS method I used was the same as using DROP PROCEDURE, since it failed after the drop.|||I don't know how the DTS task determines dependencies. If it uses say sp_depends SP then you can check by running the SP for your SP to see the dependencies. Note, that this SP only gives immediate dependencies. If this doesn't help find how DTS determines dependencies then ask in the SSIS forum or run your package and trace the calls to SQL Server.
Sunday, February 26, 2012
Drivers for DTS to Oracle
If I want to use DTS export table to Oracle from SQL Server, what all
drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
Does any other Oracle client library required.
You are going to need the Oracle client drivers from Oracle also as I
remember (SQL *Net)
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.SQLIS.com - You thought DTS was good. here we show you the new stuff.
www.konesans.com - Consultancy from the people who know
"Data Cruncher" <dcruncher4@.netscape.net> wrote in message
news:1119907568.126869.35880@.g43g2000cwa.googlegro ups.com...
> If I want to use DTS export table to Oracle from SQL Server, what all
> drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
> Does any other Oracle client library required.
>
drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
Does any other Oracle client library required.
You are going to need the Oracle client drivers from Oracle also as I
remember (SQL *Net)
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.SQLIS.com - You thought DTS was good. here we show you the new stuff.
www.konesans.com - Consultancy from the people who know
"Data Cruncher" <dcruncher4@.netscape.net> wrote in message
news:1119907568.126869.35880@.g43g2000cwa.googlegro ups.com...
> If I want to use DTS export table to Oracle from SQL Server, what all
> drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
> Does any other Oracle client library required.
>
Drivers for DTS to Oracle
If I want to use DTS export table to Oracle from SQL Server, what all
drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
Does any other Oracle client library required.You are going to need the Oracle client drivers from Oracle also as I
remember (SQL *Net)
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.SQLIS.com - You thought DTS was good. here we show you the new stuff.
www.konesans.com - Consultancy from the people who know
"Data Cruncher" <dcruncher4@.netscape.net> wrote in message
news:1119907568.126869.35880@.g43g2000cwa.googlegroups.com...
> If I want to use DTS export table to Oracle from SQL Server, what all
> drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
> Does any other Oracle client library required.
>
drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
Does any other Oracle client library required.You are going to need the Oracle client drivers from Oracle also as I
remember (SQL *Net)
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.SQLIS.com - You thought DTS was good. here we show you the new stuff.
www.konesans.com - Consultancy from the people who know
"Data Cruncher" <dcruncher4@.netscape.net> wrote in message
news:1119907568.126869.35880@.g43g2000cwa.googlegroups.com...
> If I want to use DTS export table to Oracle from SQL Server, what all
> drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
> Does any other Oracle client library required.
>
Drivers for DTS to Oracle
If I want to use DTS export table to Oracle from SQL Server, what all
drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
Does any other Oracle client library required.You are going to need the Oracle client drivers from Oracle also as I
remember (SQL *Net)
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.SQLIS.com - You thought DTS was good. here we show you the new stuff.
www.konesans.com - Consultancy from the people who know
"Data Cruncher" <dcruncher4@.netscape.net> wrote in message
news:1119907568.126869.35880@.g43g2000cwa.googlegroups.com...
> If I want to use DTS export table to Oracle from SQL Server, what all
> drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
> Does any other Oracle client library required.
>
drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
Does any other Oracle client library required.You are going to need the Oracle client drivers from Oracle also as I
remember (SQL *Net)
Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.SQLIS.com - You thought DTS was good. here we show you the new stuff.
www.konesans.com - Consultancy from the people who know
"Data Cruncher" <dcruncher4@.netscape.net> wrote in message
news:1119907568.126869.35880@.g43g2000cwa.googlegroups.com...
> If I want to use DTS export table to Oracle from SQL Server, what all
> drivers I need. One is I believe MS ODBC Driver to connect to Oracle.
> Does any other Oracle client library required.
>
Driver to connect to Informix via DTS?
Hi, folks!
I want to pump data from Informix to SQL Server using DTS to fill / fresh up my SQL-Server data warehouse every day.
In the SQL documentation I found "Don't use the ODBC driver from Informix"
Which is a good choice of ODBC/OLE-DB drivers to deal with Informix via SQL servers DTS?
Regards from Berlin!
SeBaFluDownload Informix driver from IBM website and set it up on your machine to create a DTS package. I have used it to create a DTS package and run it for over a year now.|||What was the error with current driver?
That was a general recommendation, but to followup the data import/export as referred comaptible driver must be used.|||Hi, Joe!
Originally posted by joejcheng
Download Informix driver from IBM website and set it up on your machine to create a DTS package. I have used it to create a DTS package and run it for over a year now.
OK, let's try it <s>...
... but may be I'm stupid - but I can't find any ODBC driver at the IBM site - can You advice me to the related URL?
Many thanx from Berlin!
SeBaFlu
I want to pump data from Informix to SQL Server using DTS to fill / fresh up my SQL-Server data warehouse every day.
In the SQL documentation I found "Don't use the ODBC driver from Informix"
Which is a good choice of ODBC/OLE-DB drivers to deal with Informix via SQL servers DTS?
Regards from Berlin!
SeBaFluDownload Informix driver from IBM website and set it up on your machine to create a DTS package. I have used it to create a DTS package and run it for over a year now.|||What was the error with current driver?
That was a general recommendation, but to followup the data import/export as referred comaptible driver must be used.|||Hi, Joe!
Originally posted by joejcheng
Download Informix driver from IBM website and set it up on your machine to create a DTS package. I have used it to create a DTS package and run it for over a year now.
OK, let's try it <s>...
... but may be I'm stupid - but I can't find any ODBC driver at the IBM site - can You advice me to the related URL?
Many thanx from Berlin!
SeBaFlu
Driver for paradox
Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
It's the last version of the paradox and the DTS in the sql doesn't
help,
Someone have advice?Hi
The latest Microsoft driver for paradox should be in the latest version of
MDAC, if this is not suitable you should contact Borland.
John
"noam" wrote:
> Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
> It's the last version of the paradox and the DTS in the sql doesn't
> help,
> Someone have advice?
>|||Hi
The latest Microsoft driver for paradox should be in the latest version of
MDAC, if this is not suitable you should contact Borland.
John
"noam" wrote:
> Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
> It's the last version of the paradox and the DTS in the sql doesn't
> help,
> Someone have advice?
>
It's the last version of the paradox and the DTS in the sql doesn't
help,
Someone have advice?Hi
The latest Microsoft driver for paradox should be in the latest version of
MDAC, if this is not suitable you should contact Borland.
John
"noam" wrote:
> Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
> It's the last version of the paradox and the DTS in the sql doesn't
> help,
> Someone have advice?
>|||Hi
The latest Microsoft driver for paradox should be in the latest version of
MDAC, if this is not suitable you should contact Borland.
John
"noam" wrote:
> Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
> It's the last version of the paradox and the DTS in the sql doesn't
> help,
> Someone have advice?
>
Driver for paradox
Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
It's the last version of the paradox and the DTS in the sql doesn't
help,
Someone have advice?Hi
The latest Microsoft driver for paradox should be in the latest version of
MDAC, if this is not suitable you should contact Borland.
John
"noam" wrote:
> Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
> It's the last version of the paradox and the DTS in the sql doesn't
> help,
> Someone have advice?
>
It's the last version of the paradox and the DTS in the sql doesn't
help,
Someone have advice?Hi
The latest Microsoft driver for paradox should be in the latest version of
MDAC, if this is not suitable you should contact Borland.
John
"noam" wrote:
> Hi, I'm looking for driver to transfer data for paradox DB to sql DB,
> It's the last version of the paradox and the DTS in the sql doesn't
> help,
> Someone have advice?
>
Subscribe to:
Posts (Atom)