Export fails copying dbase from 1 server two another

HI I tried the export wizard mssql2000 and for several dbases it works for
most but for 1 dbase it stops after creating all the tables and just says
that it fails. I noticed that it only copies over a few of the views so not
sure if this is were the problem is. I am planning on trying to do a dbase
backup on the source machine and then copying the file to the destination
machine and doing a restore to see if this works. Any ideas?
Paul G
Software engineer.
This kind of stuff happens. Here is onle likely scenario:
You have views/procs/functions/etc that are no longer valid in your source
database. This happens by schema changes and the dependent objects hav
become obsolete, but still exist. Now when you script them out and try to
run them on the new server (which is what the export wizard is doing), you
get errors. For example, the table or a column referenced in a view no
longer exists ... crash.
Make sure to clean up your source DB and see if that helps.
HTH,
John Scragg
"Paul" wrote:

> HI I tried the export wizard mssql2000 and for several dbases it works for
> most but for 1 dbase it stops after creating all the tables and just says
> that it fails. I noticed that it only copies over a few of the views so not
> sure if this is were the problem is. I am planning on trying to do a dbase
> backup on the source machine and then copying the file to the destination
> machine and doing a restore to see if this works. Any ideas?
> --
> Paul G
> Software engineer.
|||ok thanks for the information, nice to know what is causing the problem. The
database that failed has been around for a long time so probably does need to
be cleaned up as stated.
Paul G
Software engineer.
"John Scragg" wrote:
[vbcol=seagreen]
> This kind of stuff happens. Here is onle likely scenario:
> You have views/procs/functions/etc that are no longer valid in your source
> database. This happens by schema changes and the dependent objects hav
> become obsolete, but still exist. Now when you script them out and try to
> run them on the new server (which is what the export wizard is doing), you
> get errors. For example, the table or a column referenced in a view no
> longer exists ... crash.
> Make sure to clean up your source DB and see if that helps.
> HTH,
> John Scragg
> "Paul" wrote:

Export fails copying dbase from 1 server two another

HI I tried the export wizard mssql2000 and for several dbases it works for
most but for 1 dbase it stops after creating all the tables and just says
that it fails. I noticed that it only copies over a few of the views so not
sure if this is were the problem is. I am planning on trying to do a dbase
backup on the source machine and then copying the file to the destination
machine and doing a restore to see if this works. Any ideas?
--
Paul G
Software engineer.This kind of stuff happens. Here is onle likely scenario:
You have views/procs/functions/etc that are no longer valid in your source
database. This happens by schema changes and the dependent objects hav
become obsolete, but still exist. Now when you script them out and try to
run them on the new server (which is what the export wizard is doing), you
get errors. For example, the table or a column referenced in a view no
longer exists ... crash.
Make sure to clean up your source DB and see if that helps.
HTH,
John Scragg
"Paul" wrote:

> HI I tried the export wizard mssql2000 and for several dbases it works for
> most but for 1 dbase it stops after creating all the tables and just says
> that it fails. I noticed that it only copies over a few of the views so n
ot
> sure if this is were the problem is. I am planning on trying to do a dbas
e
> backup on the source machine and then copying the file to the destination
> machine and doing a restore to see if this works. Any ideas?
> --
> Paul G
> Software engineer.|||ok thanks for the information, nice to know what is causing the problem. Th
e
database that failed has been around for a long time so probably does need t
o
be cleaned up as stated.
--
Paul G
Software engineer.
"John Scragg" wrote:
[vbcol=seagreen]
> This kind of stuff happens. Here is onle likely scenario:
> You have views/procs/functions/etc that are no longer valid in your source
> database. This happens by schema changes and the dependent objects hav
> become obsolete, but still exist. Now when you script them out and try to
> run them on the new server (which is what the export wizard is doing), you
> get errors. For example, the table or a column referenced in a view no
> longer exists ... crash.
> Make sure to clean up your source DB and see if that helps.
> HTH,
> John Scragg
> "Paul" wrote:
>sql

Export fails copying dbase from 1 server two another

HI I tried the export wizard mssql2000 and for several dbases it works for
most but for 1 dbase it stops after creating all the tables and just says
that it fails. I noticed that it only copies over a few of the views so not
sure if this is were the problem is. I am planning on trying to do a dbase
backup on the source machine and then copying the file to the destination
machine and doing a restore to see if this works. Any ideas?
--
Paul G
Software engineer.This kind of stuff happens. Here is onle likely scenario:
You have views/procs/functions/etc that are no longer valid in your source
database. This happens by schema changes and the dependent objects hav
become obsolete, but still exist. Now when you script them out and try to
run them on the new server (which is what the export wizard is doing), you
get errors. For example, the table or a column referenced in a view no
longer exists ... crash.
Make sure to clean up your source DB and see if that helps.
HTH,
John Scragg
"Paul" wrote:
> HI I tried the export wizard mssql2000 and for several dbases it works for
> most but for 1 dbase it stops after creating all the tables and just says
> that it fails. I noticed that it only copies over a few of the views so not
> sure if this is were the problem is. I am planning on trying to do a dbase
> backup on the source machine and then copying the file to the destination
> machine and doing a restore to see if this works. Any ideas?
> --
> Paul G
> Software engineer.|||ok thanks for the information, nice to know what is causing the problem. The
database that failed has been around for a long time so probably does need to
be cleaned up as stated.
--
Paul G
Software engineer.
"John Scragg" wrote:
> This kind of stuff happens. Here is onle likely scenario:
> You have views/procs/functions/etc that are no longer valid in your source
> database. This happens by schema changes and the dependent objects hav
> become obsolete, but still exist. Now when you script them out and try to
> run them on the new server (which is what the export wizard is doing), you
> get errors. For example, the table or a column referenced in a view no
> longer exists ... crash.
> Make sure to clean up your source DB and see if that helps.
> HTH,
> John Scragg
> "Paul" wrote:
> > HI I tried the export wizard mssql2000 and for several dbases it works for
> > most but for 1 dbase it stops after creating all the tables and just says
> > that it fails. I noticed that it only copies over a few of the views so not
> > sure if this is were the problem is. I am planning on trying to do a dbase
> > backup on the source machine and then copying the file to the destination
> > machine and doing a restore to see if this works. Any ideas?
> > --
> > Paul G
> > Software engineer.

Explorer Vaporization

Last night I detached a 110 Gig 2000 database on Win 2000
system and was copying it from a slow SAN drive to a
faster SAN drive. Three times in a row I observed the
same behavior:
--Windows Explorer would show the file being copied for
about ten minutes.
--After ten minutes Windows Explorer would vaporize, i.e.
disappear completely.
--Then on the new SAN drive I noticed that a 110 Gig file
was left there, i.e. Windows Explorer was not even able
to erase the failed copy.
Has anyone ever seen something like this before? Any
ideas what could cause this? (There was nothing in the
Event/App Viewer.)
Hi
Try to use command line XCOPY. Explorer does have a few quirks and is
generally slower on such big files.
Regards
Mike
"Blk" wrote:

> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
>
|||"Blk" <anonymous@.discussions.microsoft.com> schrieb im Newsbeitrag
news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
The OS was probably still writing the file. You can either wait or use a
tool like process explorer (sysinternals) to check which process has a
handle on that file.
Kind regards
robert
|||Does XCOPY give you status on a large file?

>--Original Message--
>Hi
>Try to use command line XCOPY. Explorer does have a few
quirks and is[vbcol=seagreen]
>generally slower on such big files.
>Regards
>Mike
>"Blk" wrote:
2000[vbcol=seagreen]
for[vbcol=seagreen]
i.e.[vbcol=seagreen]
file[vbcol=seagreen]
able[vbcol=seagreen]
the
>.
>
|||I don't think so, because I was able to delete the file,
i.e. there were no locks on it.

>--Original Message--
>"Blk" <anonymous@.discussions.microsoft.com> schrieb im
Newsbeitrag[vbcol=seagreen]
>news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
2000[vbcol=seagreen]
i.e.[vbcol=seagreen]
file
>The OS was probably still writing the file. You can
either wait or use a
>tool like process explorer (sysinternals) to check which
process has a
>handle on that file.
>Kind regards
> robert
>.
>
|||"Blk" <anonymous@.discussions.microsoft.com> wrote in message
news:070401c50ada$e88c3c20$a501280a@.phx.gbl...
> Does XCOPY give you status on a large file?
No, but find the resource kit for 2K and get a copy of robocopy.exe.
excellent tool.
[vbcol=seagreen]
>
> quirks and is
> 2000
> for
> i.e.
> file
> able
> the

Explorer Vaporization

Last night I detached a 110 Gig 2000 database on Win 2000
system and was copying it from a slow SAN drive to a
faster SAN drive. Three times in a row I observed the
same behavior:
--Windows Explorer would show the file being copied for
about ten minutes.
--After ten minutes Windows Explorer would vaporize, i.e.
disappear completely.
--Then on the new SAN drive I noticed that a 110 Gig file
was left there, i.e. Windows Explorer was not even able
to erase the failed copy.
Has anyone ever seen something like this before? Any
ideas what could cause this? (There was nothing in the
Event/App Viewer.)Hi
Try to use command line XCOPY. Explorer does have a few quirks and is
generally slower on such big files.
Regards
Mike
"Blk" wrote:

> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
>|||"Blk" <anonymous@.discussions.microsoft.com> schrieb im Newsbeitrag
news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
The OS was probably still writing the file. You can either wait or use a
tool like process explorer (sysinternals) to check which process has a
handle on that file.
Kind regards
robert|||Does XCOPY give you status on a large file?

>--Original Message--
>Hi
>Try to use command line XCOPY. Explorer does have a few
quirks and is
>generally slower on such big files.
>Regards
>Mike
>"Blk" wrote:
>
2000[vbcol=seagreen]
for[vbcol=seagreen]
i.e.[vbcol=seagreen]
file[vbcol=seagreen]
able[vbcol=seagreen]
the[vbcol=seagreen]
>.
>|||I don't think so, because I was able to delete the file,
i.e. there were no locks on it.

>--Original Message--
>"Blk" <anonymous@.discussions.microsoft.com> schrieb im
Newsbeitrag
>news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
2000[vbcol=seagreen]
i.e.[vbcol=seagreen]
file[vbcol=seagreen]
>The OS was probably still writing the file. You can
either wait or use a
>tool like process explorer (sysinternals) to check which
process has a
>handle on that file.
>Kind regards
> robert
>.
>|||"Blk" <anonymous@.discussions.microsoft.com> wrote in message
news:070401c50ada$e88c3c20$a501280a@.phx.gbl...
> Does XCOPY give you status on a large file?
No, but find the resource kit for 2K and get a copy of robocopy.exe.
excellent tool.
[vbcol=seagreen]
>
> quirks and is
> 2000
> for
> i.e.
> file
> able
> the

Explorer Vaporization

Last night I detached a 110 Gig 2000 database on Win 2000
system and was copying it from a slow SAN drive to a
faster SAN drive. Three times in a row I observed the
same behavior:
--Windows Explorer would show the file being copied for
about ten minutes.
--After ten minutes Windows Explorer would vaporize, i.e.
disappear completely.
--Then on the new SAN drive I noticed that a 110 Gig file
was left there, i.e. Windows Explorer was not even able
to erase the failed copy.
Has anyone ever seen something like this before? Any
ideas what could cause this? (There was nothing in the
Event/App Viewer.)Hi
Try to use command line XCOPY. Explorer does have a few quirks and is
generally slower on such big files.
Regards
Mike
"Blk" wrote:
> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
>|||"Blk" <anonymous@.discussions.microsoft.com> schrieb im Newsbeitrag
news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
> Last night I detached a 110 Gig 2000 database on Win 2000
> system and was copying it from a slow SAN drive to a
> faster SAN drive. Three times in a row I observed the
> same behavior:
> --Windows Explorer would show the file being copied for
> about ten minutes.
> --After ten minutes Windows Explorer would vaporize, i.e.
> disappear completely.
> --Then on the new SAN drive I noticed that a 110 Gig file
> was left there, i.e. Windows Explorer was not even able
> to erase the failed copy.
> Has anyone ever seen something like this before? Any
> ideas what could cause this? (There was nothing in the
> Event/App Viewer.)
The OS was probably still writing the file. You can either wait or use a
tool like process explorer (sysinternals) to check which process has a
handle on that file.
Kind regards
robert|||Does XCOPY give you status on a large file?
>--Original Message--
>Hi
>Try to use command line XCOPY. Explorer does have a few
quirks and is
>generally slower on such big files.
>Regards
>Mike
>"Blk" wrote:
>> Last night I detached a 110 Gig 2000 database on Win
2000
>> system and was copying it from a slow SAN drive to a
>> faster SAN drive. Three times in a row I observed the
>> same behavior:
>> --Windows Explorer would show the file being copied
for
>> about ten minutes.
>> --After ten minutes Windows Explorer would vaporize,
i.e.
>> disappear completely.
>> --Then on the new SAN drive I noticed that a 110 Gig
file
>> was left there, i.e. Windows Explorer was not even
able
>> to erase the failed copy.
>> Has anyone ever seen something like this before? Any
>> ideas what could cause this? (There was nothing in
the
>> Event/App Viewer.)
>.
>|||I don't think so, because I was able to delete the file,
i.e. there were no locks on it.
>--Original Message--
>"Blk" <anonymous@.discussions.microsoft.com> schrieb im
Newsbeitrag
>news:175b01c50ad3$b48046d0$a401280a@.phx.gbl...
>> Last night I detached a 110 Gig 2000 database on Win
2000
>> system and was copying it from a slow SAN drive to a
>> faster SAN drive. Three times in a row I observed the
>> same behavior:
>> --Windows Explorer would show the file being copied for
>> about ten minutes.
>> --After ten minutes Windows Explorer would vaporize,
i.e.
>> disappear completely.
>> --Then on the new SAN drive I noticed that a 110 Gig
file
>> was left there, i.e. Windows Explorer was not even able
>> to erase the failed copy.
>> Has anyone ever seen something like this before? Any
>> ideas what could cause this? (There was nothing in the
>> Event/App Viewer.)
>The OS was probably still writing the file. You can
either wait or use a
>tool like process explorer (sysinternals) to check which
process has a
>handle on that file.
>Kind regards
> robert
>.
>|||"Blk" <anonymous@.discussions.microsoft.com> wrote in message
news:070401c50ada$e88c3c20$a501280a@.phx.gbl...
> Does XCOPY give you status on a large file?
No, but find the resource kit for 2K and get a copy of robocopy.exe.
excellent tool.
>
> >--Original Message--
> >Hi
> >
> >Try to use command line XCOPY. Explorer does have a few
> quirks and is
> >generally slower on such big files.
> >
> >Regards
> >Mike
> >
> >"Blk" wrote:
> >
> >> Last night I detached a 110 Gig 2000 database on Win
> 2000
> >> system and was copying it from a slow SAN drive to a
> >> faster SAN drive. Three times in a row I observed the
> >> same behavior:
> >>
> >> --Windows Explorer would show the file being copied
> for
> >> about ten minutes.
> >> --After ten minutes Windows Explorer would vaporize,
> i.e.
> >> disappear completely.
> >> --Then on the new SAN drive I noticed that a 110 Gig
> file
> >> was left there, i.e. Windows Explorer was not even
> able
> >> to erase the failed copy.
> >>
> >> Has anyone ever seen something like this before? Any
> >> ideas what could cause this? (There was nothing in
> the
> >> Event/App Viewer.)
> >>
> >.
> >