Cannot copy indexes w 2005 Import/Export Wizard

In SQL 2000, the 'Copy SQL Server Objects' task allows 'copy indexes' under
'Advanced Copy Options' when transferring tables. But I cannot see where the
SQL 2005 Import and Export Wizard allows this option. Is there an easy way
to do this (I hope) ?Hello Mark,
You could check "Transfer SQL server objects" task in SSIS project in
VS.net 2005. DTS is ugpraded to SSIS in SQL 2005.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
--
>Thread-Topic: Cannot copy indexes w 2005 Import/Export Wizard
>thread-index: AcYnif7U0qKGdOuRRFuiyisljvKhWg==
>X-WBNR-Posting-Host: 67.96.43.11
>From: "examnotes" <markgsch@.noemail.noemail>
>Subject: Cannot copy indexes w 2005 Import/Export Wizard
>Date: Wed, 1 Feb 2006 15:48:26 -0800
>Lines: 4
>Message-ID: <D1072BA0-E4FF-4E06-8F4C-018F334730F9@.microsoft.com>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="Utf-8"
>Content-Transfer-Encoding: 7bit
>X-Newsreader: Microsoft CDO for Windows 2000
>Content-Class: urn:content-classes:message
>Importance: normal
>Priority: normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups: microsoft.public.sqlserver.server
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
>Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.sqlserver.server:419786
>X-Tomcat-NG: microsoft.public.sqlserver.server
>In SQL 2000, the 'Copy SQL Server Objects' task allows 'copy indexes'
under
>'Advanced Copy Options' when transferring tables. But I cannot see where
the
>SQL 2005 Import and Export Wizard allows this option. Is there an easy
way
>to do this (I hope) ?
>

Cannot copy indexes w 2005 Import/Export Wizard

In SQL 2000, the 'Copy SQL Server Objects' task allows 'copy indexes' under
'Advanced Copy Options' when transferring tables. But I cannot see where the
SQL 2005 Import and Export Wizard allows this option. Is there an easy way
to do this (I hope) ?Hello Mark,
You could check "Transfer SQL server objects" task in SSIS project in
VS.net 2005. DTS is ugpraded to SSIS in SQL 2005.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
>Thread-Topic: Cannot copy indexes w 2005 Import/Export Wizard
>thread-index: AcYnif7U0qKGdOuRRFuiyisljvKhWg==>X-WBNR-Posting-Host: 67.96.43.11
>From: "=?Utf-8?B?TWFya0dzY2g=?=" <markgsch@.noemail.noemail>
>Subject: Cannot copy indexes w 2005 Import/Export Wizard
>Date: Wed, 1 Feb 2006 15:48:26 -0800
>Lines: 4
>Message-ID: <D1072BA0-E4FF-4E06-8F4C-018F334730F9@.microsoft.com>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="Utf-8"
>Content-Transfer-Encoding: 7bit
>X-Newsreader: Microsoft CDO for Windows 2000
>Content-Class: urn:content-classes:message
>Importance: normal
>Priority: normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups: microsoft.public.sqlserver.server
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
>Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.sqlserver.server:419786
>X-Tomcat-NG: microsoft.public.sqlserver.server
>In SQL 2000, the 'Copy SQL Server Objects' task allows 'copy indexes'
under
>'Advanced Copy Options' when transferring tables. But I cannot see where
the
>SQL 2005 Import and Export Wizard allows this option. Is there an easy
way
>to do this (I hope) ?
>

Cannot copy : Insufficient system resources

Production Server: Win2k Advanced Server, SQL 2k Advanced Server, Both fully
patched, 4 processors, 5 GB RAM, 320 GB partition, 68 GB DataBase, SAN, 2 2GB
Fiber NICS teamed
Development Server: Win2k Server, SQL 2k Server, two processors, 2 GB RAM,
Raid 5 SCSI controller, 4 100 mb NICS teamed
Both servers have lots of room on the partition.
We've been refreshing the development server with fresh production data
every three months. My method for doing this has been to do a local backup of
the production server, then copy the bak file to the development server. This
has been working for several years. The bak file is now 70 GB. The last time
it worked the bak file was around 65 GB. Last night the copy of the bak file
over the network failed about halfway through with a popup:
"Cannot copy prd. bak : Insufficient system resources exist to complete the
requested service" There are no entries in either server's application or
system event logs. I've read the MSFT KB Article 259837 but that doesn't seem
to apply because (a) the failure occured about one hour into the copy process
and (b) both servers are fully patched.
Developers are beating on me to get this done tonight. I suspect in the long
run, I will have to get something like SQL lite speed. But I would like a
quick fix for tonight. I would prefer not to shut down the production db and
copy the individual files.
Here are my thoughts:
1. Would I have better luck if I backed up with a UNC path to the
development server?
2. Can I compress the bak file with something?
Any suggestions?Personally, I prefer working with UNC paths for backups.
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/default.aspx?scid=kb;en-us;555128
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"MangroveGeek" <carl@.tenthousandislands.net(DoNotSpam)> wrote in message
news:130BD949-316B-44F2-9117-B30B9477D24C@.microsoft.com...
> Production Server: Win2k Advanced Server, SQL 2k Advanced Server, Both
> fully
> patched, 4 processors, 5 GB RAM, 320 GB partition, 68 GB DataBase, SAN, 2
> 2GB
> Fiber NICS teamed
> Development Server: Win2k Server, SQL 2k Server, two processors, 2 GB RAM,
> Raid 5 SCSI controller, 4 100 mb NICS teamed
> Both servers have lots of room on the partition.
> We've been refreshing the development server with fresh production data
> every three months. My method for doing this has been to do a local backup
> of
> the production server, then copy the bak file to the development server.
> This
> has been working for several years. The bak file is now 70 GB. The last
> time
> it worked the bak file was around 65 GB. Last night the copy of the bak
> file
> over the network failed about halfway through with a popup:
> "Cannot copy prd. bak : Insufficient system resources exist to complete
> the
> requested service" There are no entries in either server's application or
> system event logs. I've read the MSFT KB Article 259837 but that doesn't
> seem
> to apply because (a) the failure occured about one hour into the copy
> process
> and (b) both servers are fully patched.
> Developers are beating on me to get this done tonight. I suspect in the
> long
> run, I will have to get something like SQL lite speed. But I would like a
> quick fix for tonight. I would prefer not to shut down the production db
> and
> copy the individual files.
> Here are my thoughts:
> 1. Would I have better luck if I backed up with a UNC path to the
> development server?
> 2. Can I compress the bak file with something?
> Any suggestions?

Cannot copy : Insufficient system resources

Production Server: Win2k Advanced Server, SQL 2k Advanced Server, Both fully
patched, 4 processors, 5 GB RAM, 320 GB partition, 68 GB DataBase, SAN, 2 2G
B
Fiber NICS teamed
Development Server: Win2k Server, SQL 2k Server, two processors, 2 GB RAM,
Raid 5 SCSI controller, 4 100 mb NICS teamed
Both servers have lots of room on the partition.
We've been refreshing the development server with fresh production data
every three months. My method for doing this has been to do a local backup o
f
the production server, then copy the bak file to the development server. Thi
s
has been working for several years. The bak file is now 70 GB. The last time
it worked the bak file was around 65 GB. Last night the copy of the bak file
over the network failed about halfway through with a popup:
"Cannot copy prd. bak : Insufficient system resources exist to complete the
requested service" There are no entries in either server's application or
system event logs. I've read the MSFT KB Article 259837 but that doesn't see
m
to apply because (a) the failure occured about one hour into the copy proces
s
and (b) both servers are fully patched.
Developers are beating on me to get this done tonight. I suspect in the long
run, I will have to get something like SQL lite speed. But I would like a
quick fix for tonight. I would prefer not to shut down the production db and
copy the individual files.
Here are my thoughts:
1. Would I have better luck if I backed up with a UNC path to the
development server?
2. Can I compress the bak file with something?
Any suggestions?Personally, I prefer working with UNC paths for backups.
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/defaul...kb;en-us;555128
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"MangroveGeek" <carl@.tenthousandislands.net(DoNotSpam)> wrote in message
news:130BD949-316B-44F2-9117-B30B9477D24C@.microsoft.com...
> Production Server: Win2k Advanced Server, SQL 2k Advanced Server, Both
> fully
> patched, 4 processors, 5 GB RAM, 320 GB partition, 68 GB DataBase, SAN, 2
> 2GB
> Fiber NICS teamed
> Development Server: Win2k Server, SQL 2k Server, two processors, 2 GB RAM,
> Raid 5 SCSI controller, 4 100 mb NICS teamed
> Both servers have lots of room on the partition.
> We've been refreshing the development server with fresh production data
> every three months. My method for doing this has been to do a local backup
> of
> the production server, then copy the bak file to the development server.
> This
> has been working for several years. The bak file is now 70 GB. The last
> time
> it worked the bak file was around 65 GB. Last night the copy of the bak
> file
> over the network failed about halfway through with a popup:
> "Cannot copy prd. bak : Insufficient system resources exist to complete
> the
> requested service" There are no entries in either server's application or
> system event logs. I've read the MSFT KB Article 259837 but that doesn't
> seem
> to apply because (a) the failure occured about one hour into the copy
> process
> and (b) both servers are fully patched.
> Developers are beating on me to get this done tonight. I suspect in the
> long
> run, I will have to get something like SQL lite speed. But I would like a
> quick fix for tonight. I would prefer not to shut down the production db
> and
> copy the individual files.
> Here are my thoughts:
> 1. Would I have better luck if I backed up with a UNC path to the
> development server?
> 2. Can I compress the bak file with something?
> Any suggestions?

Cannot copy : Insufficient system resources

Production Server: Win2k Advanced Server, SQL 2k Advanced Server, Both fully
patched, 4 processors, 5 GB RAM, 320 GB partition, 68 GB DataBase, SAN, 2 2GB
Fiber NICS teamed
Development Server: Win2k Server, SQL 2k Server, two processors, 2 GB RAM,
Raid 5 SCSI controller, 4 100 mb NICS teamed
Both servers have lots of room on the partition.
We've been refreshing the development server with fresh production data
every three months. My method for doing this has been to do a local backup of
the production server, then copy the bak file to the development server. This
has been working for several years. The bak file is now 70 GB. The last time
it worked the bak file was around 65 GB. Last night the copy of the bak file
over the network failed about halfway through with a popup:
"Cannot copy prd. bak : Insufficient system resources exist to complete the
requested service" There are no entries in either server's application or
system event logs. I've read the MSFT KB Article 259837 but that doesn't seem
to apply because (a) the failure occured about one hour into the copy process
and (b) both servers are fully patched.
Developers are beating on me to get this done tonight. I suspect in the long
run, I will have to get something like SQL lite speed. But I would like a
quick fix for tonight. I would prefer not to shut down the production db and
copy the individual files.
Here are my thoughts:
1. Would I have better luck if I backed up with a UNC path to the
development server?
2. Can I compress the bak file with something?
Any suggestions?
Personally, I prefer working with UNC paths for backups.
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/default...b;en-us;555128
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"MangroveGeek" <carl@.tenthousandislands.net(DoNotSpam)> wrote in message
news:130BD949-316B-44F2-9117-B30B9477D24C@.microsoft.com...
> Production Server: Win2k Advanced Server, SQL 2k Advanced Server, Both
> fully
> patched, 4 processors, 5 GB RAM, 320 GB partition, 68 GB DataBase, SAN, 2
> 2GB
> Fiber NICS teamed
> Development Server: Win2k Server, SQL 2k Server, two processors, 2 GB RAM,
> Raid 5 SCSI controller, 4 100 mb NICS teamed
> Both servers have lots of room on the partition.
> We've been refreshing the development server with fresh production data
> every three months. My method for doing this has been to do a local backup
> of
> the production server, then copy the bak file to the development server.
> This
> has been working for several years. The bak file is now 70 GB. The last
> time
> it worked the bak file was around 65 GB. Last night the copy of the bak
> file
> over the network failed about halfway through with a popup:
> "Cannot copy prd. bak : Insufficient system resources exist to complete
> the
> requested service" There are no entries in either server's application or
> system event logs. I've read the MSFT KB Article 259837 but that doesn't
> seem
> to apply because (a) the failure occured about one hour into the copy
> process
> and (b) both servers are fully patched.
> Developers are beating on me to get this done tonight. I suspect in the
> long
> run, I will have to get something like SQL lite speed. But I would like a
> quick fix for tonight. I would prefer not to shut down the production db
> and
> copy the individual files.
> Here are my thoughts:
> 1. Would I have better luck if I backed up with a UNC path to the
> development server?
> 2. Can I compress the bak file with something?
> Any suggestions?