|
Home > Archive > microsoft.public.sqlserver.server > October 2002 > How to export, transport, import
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to export, transport, import
|
|
| Henk Schreij 2002-10-05, 9:11 pm |
| Using MS SQL server 7, I want to extract a table from a database at home,
send it (by email attachment) to the office and there install it again.
What is the best way to do it.
I think a way is:
-at home: export the table to a textfile (csv) with column names.
-send this file by email to the office
-delete the old file (or rename it to filenameOld) in the office database
-import the csv file
-repair the defaults, nullability, field types/precision/length, keys
-hope all went well.
I also tried a xls file, but this is more or less the same.
Is there a better way to do this?
Any hint is welcome
| |
|
| > -at home: export the table to a textfile (csv) with column names.
See BCP inBOL.
> -repair the defaults, nullability, field types/precision/length, keys
Script out the table at home so you have the proper table structure.
"Henk Schreij" <henk@schreijDOTnlNO.com> wrote in message
news:ea4VtwHYCHA.1732@tkmsftngp10...
> Using MS SQL server 7, I want to extract a table from a database at home,
> send it (by email attachment) to the office and there install it again.
> What is the best way to do it.
> I think a way is:
> -at home: export the table to a textfile (csv) with column names.
> -send this file by email to the office
> -delete the old file (or rename it to filenameOld) in the office database
> -import the csv file
> -repair the defaults, nullability, field types/precision/length, keys
> -hope all went well.
> I also tried a xls file, but this is more or less the same.
>
> Is there a better way to do this?
> Any hint is welcome
>
>
| |
| Russell Fields 2002-10-05, 9:12 pm |
| Henk
Your way works, but what I don't understand is why deleting the data and
replacing it would require you to repair the defaults, nullability, etc.
Unless you actually drop the table all of those things should remain.
(Unless your home system does not support the data integrity concerns of
your work system.)
Another thing to think about could be snapshot replication. This requires a
little set up on your part, but prepares replication files that can be moved
to the target server. Read up on this topic in the Books Online and see if
that seems better to you.
Russell Fields
"Henk Schreij" <henk@schreijDOTnlNO.com> wrote in message
news:ea4VtwHYCHA.1732@tkmsftngp10...
> Using MS SQL server 7, I want to extract a table from a database at home,
> send it (by email attachment) to the office and there install it again.
> What is the best way to do it.
> I think a way is:
> -at home: export the table to a textfile (csv) with column names.
> -send this file by email to the office
> -delete the old file (or rename it to filenameOld) in the office database
> -import the csv file
> -repair the defaults, nullability, field types/precision/length, keys
> -hope all went well.
> I also tried a xls file, but this is more or less the same.
>
> Is there a better way to do this?
> Any hint is welcome
>
>
| |
| Henk Schreij 2002-10-05, 9:12 pm |
| Russell, thank you for your answer.
"Russell Fields" <rlfields@sprynet.com> wrote in
news:uez0OpKYCHA.1728@tkmsftngp08...
> Your way works, but what I don't understand is why deleting the data and
> replacing it would require you to repair the defaults, nullability, etc.
> Unless you actually drop the table all of those things should remain.
For your information:
At home I have a test database, from a older date. The table concerned is a
history table.
At the office they forgot to extract the history data and overwrote the
needed data for the history.
I managed to reproduce the needed data from my test database.
The problem is, how to get them in the database at the office.
Indeed, I drop the table.
Should I delete all records and use
INSERT INTO MyTable SELECT * FROM MyImportTable
(My Table is the table in the office,
MyImportTable is the imported CVS table)
But will this work?
The table structures are not the same.
I.E. a decimal type is a float type in the import table, the field length is
much longer, etc.
Cris wrote:
Script out the table at home so you have the proper table structure.
Would this be a solution?
But how could I apply the scripted structure to MyImportTable.
A problem is that I am a newbie in SQLServer, used to work with dBase,
Paradox.
> Another thing to think about could be snapshot replication. This requires
a
> little set up on your part but prepares replication files that can be
moved
> to the target server. Read up on this topic in the Books Online and see if
> that seems better to you.
I think this is to difficult for me, being a newbie on sqlserver.
|
|
|
|
|