Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Initialisation file Expand / Collapse
Author
Message
Posted Wednesday, January 02, 2013 7:26 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 10:55 AM
Points: 67, Visits: 265
Hi,

I'm totally new to SQL Server *.sql command files. I'd like to create a SQL file that runs the initialisation of the whole DB, as I need it often. Something like deleting values in certain tables, updating values in others, so that after running it the DB looks exactly like before use.

My main doubt is: Can all these commands be placed one after another, like:

DELETE FROM tblIDNames
....
UPDATE tblIDValues SET IDNumber=0, .....

etc

or is anything else needed for this to work (vars, declarations....)?

A link or a simple example would be appreciated. Thanks in advance, A.
Post #1401831
Posted Wednesday, January 02, 2013 8:12 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:31 AM
Points: 150, Visits: 1,018
Why in that way? Why don't you use backup and restore? Or you can make script for DB creation, with or without data from SSMS.
Post #1401868
Posted Wednesday, January 02, 2013 9:37 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:22 AM
Points: 6,693, Visits: 11,707
a_ud (1/2/2013)
My main doubt is: Can all these commands be placed one after another, like:

DELETE FROM tblIDNames
....
UPDATE tblIDValues SET IDNumber=0, .....

etc

Sure. Use a batch separator to separate different "chunks" of code that you want to run together. e.g.

DECLARE @variable_name INT;
SET @variable_name = 10;
DELETE FROM tblIDNames WHERE nameID < @variable_name;
GO -- << GO is the default batch separator for SSMS query windows and sqlcmd.exe scripts
UPDATE tblIDValues SET IDNumber=0
WHERE nameID < @variable_name; -- this would generate an error because @variable_name does not exist in this scope, it was declared in a previous batch
GO

When were you thinking of running your script? Many times I restore a copy of a production database into a development environment and I want to run a script after the restore completes to cleanse sensitive data as well as change settings in parameters tables to reflect the development environment.


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1401922
Posted Wednesday, January 02, 2013 10:03 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 10:55 AM
Points: 67, Visits: 265
Thaks opc.three, that makes it clearer.

For me scripts are way more practical than restores. With the scripts all I want is to delete dummy data that I use while developing the DB.
Post #1401944
Posted Wednesday, January 02, 2013 10:10 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:22 AM
Points: 6,693, Visits: 11,707
Makes perfect sense. You're quite welcome.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1401948
Posted Monday, January 07, 2013 10:51 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:42 AM
Points: 2,338, Visits: 3,158
Why not use:

TRUNCATE TABLE tblIDNames


Instead of:

DELETE FROM tblIDNames





No loops! No CURSORs! No RBAR! Hoo-uh!

INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Are you too recursively challenged?
Splitting strings based on patterns can be fast!
Post #1403973
Posted Tuesday, January 08, 2013 2:18 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 10:55 AM
Points: 67, Visits: 265
I just didn't think of it, but thank you. I've checked the TRUNCATE command and apparently one of the best things about it is that it doesn't fire the triggers (which my DB has in abondance!).
Post #1404065
Posted Tuesday, January 08, 2013 2:20 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:42 AM
Points: 2,338, Visits: 3,158
a_ud (1/8/2013)
I just didn't think of it, but thank you. I've checked the TRUNCATE command and apparently one of the best things about it is that it doesn't fire the triggers (which my DB has in abondance!).


Yes and it will generally run faster than DELETE because it doesn't update the logs either.



No loops! No CURSORs! No RBAR! Hoo-uh!

INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Are you too recursively challenged?
Splitting strings based on patterns can be fast!
Post #1404067
Posted Tuesday, January 08, 2013 7:53 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:22 AM
Points: 6,693, Visits: 11,707
dwain.c (1/8/2013)
a_ud (1/8/2013)
I just didn't think of it, but thank you. I've checked the TRUNCATE command and apparently one of the best things about it is that it doesn't fire the triggers (which my DB has in abondance!).


Yes and it will generally run faster than DELETE because it doesn't update the logs either.

It is true that TRUNCATE TABLE will generally run faster than DELETE for non-trivial amounts of data but all activity associated with the statement is still written to the transaction log. With TRUNCATE TABLE it is only page deallocations that are logged instead of the actual row deletions on those pages which is what makes it faster than DELETE.

There are a couple behavioral things to be aware of with TRUNCATE that I thought I would pass along:

1. TRUNCATE TABLE resets an IDENTITY column to its initial seed value, which may be a good thing in a test environment, but maybe not.
2. You cannot truncate a table that is referenced by a foreign key.

USE tempdb;
GO
CREATE TABLE a (id INT NOT NULL PRIMARY KEY);
GO
CREATE TABLE b (id INT NOT NULL REFERENCES a(id));
GO
TRUNCATE TABLE a;
GO



__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1404256
Posted Tuesday, January 08, 2013 5:23 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:42 AM
Points: 2,338, Visits: 3,158
opc.three (1/8/2013)
dwain.c (1/8/2013)
a_ud (1/8/2013)
I just didn't think of it, but thank you. I've checked the TRUNCATE command and apparently one of the best things about it is that it doesn't fire the triggers (which my DB has in abondance!).


Yes and it will generally run faster than DELETE because it doesn't update the logs either.

It is true that TRUNCATE TABLE will generally run faster than DELETE for non-trivial amounts of data but all activity associated with the statement is still written to the transaction log. With TRUNCATE TABLE it is only page deallocations that are logged instead of the actual row deletions on those pages which is what makes it faster than DELETE.


Good point of clarification that I forgot about.

opc.three (1/8/2013)
There are a couple behavioral things to be aware of with TRUNCATE that I thought I would pass along:

1. TRUNCATE TABLE resets an IDENTITY column to its initial seed value, which may be a good thing in a test environment, but maybe not.
2. You cannot truncate a table that is referenced by a foreign key.

USE tempdb;
GO
CREATE TABLE a (id INT NOT NULL PRIMARY KEY);
GO
CREATE TABLE b (id INT NOT NULL REFERENCES a(id));
GO
TRUNCATE TABLE a;
GO



But isn't it true that you can TRUNCATE TABLE b first and then TRUNCATE TABLE a?



No loops! No CURSORs! No RBAR! Hoo-uh!

INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Are you too recursively challenged?
Splitting strings based on patterns can be fast!
Post #1404503
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse