 |
BorlandTalk.com Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Alan T Guest
|
Posted: Wed May 02, 2007 6:38 am Post subject: Zip the SQL Server database |
|
|
Hi,
I would like to zip up the database in cases of MS Access and SQL Server.
There is no problem in Access but have no idea how do I zip up the SQL
Server database. |
|
| Back to top |
|
 |
Craig Guest
|
Posted: Wed May 02, 2007 6:54 am Post subject: Re: Zip the SQL Server database |
|
|
| Quote: |
I would like to zip up the database in cases of MS Access and SQL Server.
There is no problem in Access but have no idea how do I zip up the SQL
Server database.
|
When you say you want to zip it up I am not sure what you mean. Do you
want to zip it up so you can email it to someone? If so you should
detach the database in with sp_detach_db and then just zip up the data
file and the log file. Do you know where to find the data and log files?
Craig. |
|
| Back to top |
|
 |
Brian Bushay TeamB Guest
|
Posted: Wed May 02, 2007 7:32 am Post subject: Re: Zip the SQL Server database |
|
|
| Quote: | I would like to zip up the database in cases of MS Access and SQL Server.
There is no problem in Access but have no idea how do I zip up the SQL
Server database.
|
You will first need to Detach the database from the server. Then you can zip
the two files that make up the database.
See DetachDB in SQL Books online
--
Brian Bushay (TeamB)
Bbushay (AT) NMPLS (DOT) com |
|
| Back to top |
|
 |
Bill Todd Guest
|
Posted: Wed May 02, 2007 8:06 am Post subject: Re: Zip the SQL Server database |
|
|
Instead of detaching the database then zipping the database and log why
not backup the database, zip the backup file then perform a restore at
the destination.
--
Bill Todd (TeamB) |
|
| Back to top |
|
 |
Gary Wardell Guest
|
Posted: Thu May 03, 2007 6:47 pm Post subject: Re: Zip the SQL Server database |
|
|
If the idea is to send it to another location,
And if the database is set to "Full" recovery, I would reommend doing a full
backup and a transaction log backup to remove no longer used log records. I
belive this can also be accomplished by setting the Recovery Model to
Simple. (you would want to set it back to Full after the move.)
Then shrink the database to with Move Pages to Beginning of File checked.
This will make your database smaller and result in a smaller zip file. That
savings can be considerable.
It doesn't seem to make much difference if you detach or backup. The only
difference I've noticed is one way you have two files to zip and the other
only one. But once it's zipped there is only one either way.
On the destination machine simply attach the database (mdf file). I
recommend also setting the proper database owner.
If you did a backup instead, then restored the backup. There is one tricky
part here, if the drive layout/database location is different than the
source machine you'll need to adjust for that on the Restore Database
Options tab (I use Enterprise Manager for this) You can edit the names in
the grid to suite your situation. Notice that one column is the logical
file name in the backup and the other column is the physical file on the
destination hard drive.
After moving the database you will have to reconnect your now orphaned
users. This is explained in books Online and in a few KB articles.
Sometimes it's easier to delete all of the users except one, the dbo, before
the move and then re add them on the target server.
Hope this helps. |
|
| Back to top |
|
 |
Alan T Guest
|
Posted: Fri May 04, 2007 5:52 am Post subject: Re: Zip the SQL Server database |
|
|
Hi,
This is our situation: sometimes our client have problem in the application,
we want them to send us their database file to investigate. So they need to
make a copy of the database, strip off some confidential data like employee
table fields, eg. name, dob, gender, address...etc.
The steps are as follows in our application:
1) User press a button in the application
2) Our application will make a copy of the database
2) Replace personal data with dummy data of that copy
3) Zip that copy up
Then the client will send the zipped file by email to us.
"Gary Wardell" <nospam (AT) sample (DOT) com> wrote in message
news:4639e815$1 (AT) newsgroups (DOT) borland.com...
| Quote: | If the idea is to send it to another location,
And if the database is set to "Full" recovery, I would reommend doing a
full
backup and a transaction log backup to remove no longer used log records.
I
belive this can also be accomplished by setting the Recovery Model to
Simple. (you would want to set it back to Full after the move.)
Then shrink the database to with Move Pages to Beginning of File checked.
This will make your database smaller and result in a smaller zip file.
That
savings can be considerable.
It doesn't seem to make much difference if you detach or backup. The only
difference I've noticed is one way you have two files to zip and the other
only one. But once it's zipped there is only one either way.
On the destination machine simply attach the database (mdf file). I
recommend also setting the proper database owner.
If you did a backup instead, then restored the backup. There is one
tricky
part here, if the drive layout/database location is different than the
source machine you'll need to adjust for that on the Restore Database
Options tab (I use Enterprise Manager for this) You can edit the names in
the grid to suite your situation. Notice that one column is the logical
file name in the backup and the other column is the physical file on the
destination hard drive.
After moving the database you will have to reconnect your now orphaned
users. This is explained in books Online and in a few KB articles.
Sometimes it's easier to delete all of the users except one, the dbo,
before
the move and then re add them on the target server.
Hope this helps.
|
|
|
| Back to top |
|
 |
Alan T Guest
|
Posted: Mon May 07, 2007 5:15 pm Post subject: Re: Zip the SQL Server database |
|
|
Hi,
If my situation is too complicated, can I do this for the SQL Server
database:
1) Export the database into a text file
2) During the data export, replace the firstname and lastname field of a
table with some string like yymmdd_1..etc?
"Alan T" <alanpltseNOSPAM (AT) yahoo (DOT) com.au> wrote in message
news:463a83c6 (AT) newsgroups (DOT) borland.com...
| Quote: | Hi,
This is our situation: sometimes our client have problem in the
application, we want them to send us their database file to investigate.
So they need to make a copy of the database, strip off some confidential
data like employee table fields, eg. name, dob, gender, address...etc.
The steps are as follows in our application:
1) User press a button in the application
2) Our application will make a copy of the database
2) Replace personal data with dummy data of that copy
3) Zip that copy up
Then the client will send the zipped file by email to us.
"Gary Wardell" <nospam (AT) sample (DOT) com> wrote in message
news:4639e815$1 (AT) newsgroups (DOT) borland.com...
If the idea is to send it to another location,
And if the database is set to "Full" recovery, I would reommend doing a
full
backup and a transaction log backup to remove no longer used log records.
I
belive this can also be accomplished by setting the Recovery Model to
Simple. (you would want to set it back to Full after the move.)
Then shrink the database to with Move Pages to Beginning of File checked.
This will make your database smaller and result in a smaller zip file.
That
savings can be considerable.
It doesn't seem to make much difference if you detach or backup. The
only
difference I've noticed is one way you have two files to zip and the
other
only one. But once it's zipped there is only one either way.
On the destination machine simply attach the database (mdf file). I
recommend also setting the proper database owner.
If you did a backup instead, then restored the backup. There is one
tricky
part here, if the drive layout/database location is different than the
source machine you'll need to adjust for that on the Restore Database
Options tab (I use Enterprise Manager for this) You can edit the names
in
the grid to suite your situation. Notice that one column is the logical
file name in the backup and the other column is the physical file on the
destination hard drive.
After moving the database you will have to reconnect your now orphaned
users. This is explained in books Online and in a few KB articles.
Sometimes it's easier to delete all of the users except one, the dbo,
before
the move and then re add them on the target server.
Hope this helps.
|
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|