InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comMon, 20 May 2013 08:47:42 GMT20http://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspx[quote][b]Snargables (1/16/2013)[/b][hr]actually. no. i shouldn't have any security issues running sql smd prompt manually. i was thinking of running it in script call or via job. I'll give that a try in a lil while. thanks[/quote]If you can't, and you're the DBA, get it set up so you can.Take a look at the uses of the "Dedicated Admin Connection" (DAC) for why it's important. There will be times when a more complex client won't be able to deal with an unstable SQL Server instance, but DAC + sqlcmd will be. Important to plan for that. (DAC can also be accessed via on-server-SSMS, but if the server is running out of RAM and/or CPU resources, the command prompt takes less resources and might work even if SSMS can't start.)Wed, 16 Jan 2013 18:46:42 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxactually. no. i shouldn't have any security issues running sql smd prompt manually. i was thinking of running it in script call or via job. I'll give that a try in a lil while. thanksWed, 16 Jan 2013 11:11:17 GMTSnargableshttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxIf you run SQLCMD via command line, you can set it to run as your user account (or the one you plan to make changes with). I believe the poster that referenced SQLCMD in this fashion, not via SSMS.You still have a block against that?Write a batch file with the following (assuming your BINN folder is in the path variable):sqlcmd -U MyLogin -S <ComputerName>\<InstanceName> -i <MyScript.sql> -o <MyOutput.rpt>create a separate line for each script. the rpt data will allow you to see the results of each step. I'm not batch champion but you could even incorporate some error logic I think to get it to stop in case you have problems with one line. You have access to google/bing/yahoobing so you can find that part out on your own.If you're using a different user account and it's windows based, I'd open your command line via that account (shift right click, Run as Different User).You could always test the technique by doing a simple select in your sql file...Wed, 16 Jan 2013 09:41:45 GMTsqlPirate_Flhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxOh, and as far as Joe goes. As my dad used to say. "Every a-hole's got an opinion." I thought it was funny. I sent the post to all my friends. It’s was classic. He actually stated I was a detriment to society. That’s good stuff.Well, funny and disturbing at the same time. I looked him up. He knows his stuff. We can't deny that. The disturbing part is the fact that here’s a guy at the top of his field, an expert sql guy and he has nothing better to do but trolling the web searching for people to spew his elitist jargon upon. It’s sad really. I'd like to think I’d be fishing in Bermuda of diving somewhere sipping a cocktail w/ my beautiful wife and chocolate lab.Wed, 16 Jan 2013 08:08:44 GMTSnargableshttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxThere are ways to put more robust error handling into scripts like that, but I'm not suggesting them because they'd take a lot of editing, and you don't have time/resources to do that right now from what I gather.There are ways to handle errors and rollbacks/commits even across batches. Have you used RedGate SQL Compare? Take a look at how they do error handling in the scripts that generates and you'll see a working example of it. (If you haven't played with that, I think you can get a free trial copy, and you can take a look at it that way.) But that would require significant editing of your script files.This situation is really something that has to be planned for and worked into the solution right from the beginning. Not sure how to handle it, coming in when the scripts have already been written and your go-live deadline is looming.Wed, 16 Jan 2013 08:03:16 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspx1) Sql cmd exe is disabled on all prod sql instances due to security issues. 2) I can’t add them all to 1 script because it’s dropping and creating objects as well as loading data. Because the scripts are laden w/ “go” throughout if the portion before a go fails the second portion will run regardless. So, for example. If after say the second batch is an insert that fails and say 400 batches later is another insert into a table that uses the initial table whose insert failed. Then it would insert 0 records and so on. I can’t have that.So the separation of the scripts is kind of a failsafe to ensure the process doesn’t get too far if something fails. Again, I didn’t write this. Just stating the facts. So combine all into one is not an option at this point. If file three fails I need to run it till it succeeds before I run file four. Each script is written in a way that it’s self-healing in a sense. If a script fails half way I can rerun the whole script and everything is dropped and recreated. Which is actually part of the problem. It take around 18 hours to run all the files and I have a short window of time to get it done once we do the final push. The rub is u can’t drop and create certain object w/o a GO in between. As my original example states. U can’t drop a function then create a function w/o running them in separate batches. Unless I’m missing something. Is there some other method other than using GO? To be honest, it shouldn’t blindly drop and recreate. It should be checking for existence and creating if it doesn’t exist instead of blindly dropping and recreating.It should have drop and create objects script then a data load script. Keep in mind the current process works It’s a bit manual but it works. So it’s not imperative I find a solution. It’s just been on my mind lately. So worst case I kick one off. Then 1.32 hours later when I expect it’s done I manually check. If all is good I kick off the next script. I was just hoping to automate it and have it send me success or failure emails.Actually at the very least I could have it send me a completion email at the end of each script. I think I’ll add that now. Just thinking out loud. Again. I wouldn’t waste too much mental energy on this because I do have a working method. Wed, 16 Jan 2013 07:48:17 GMTSnargableshttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxThe "sqlcmd" utility does recognize "GO", as well as many other things, including invoking OS cmds.I think you should be able to use "sqlcmd" to run the scripts.Tue, 15 Jan 2013 15:25:26 GMTScottPletcherhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxYeah, it's pretty safe to ignore [strike]the rabid weasle[/strike] Joe in this instance. Nothing he wrote here actually has any value to the discussion. (Sometimes it does, and it's just poorly communicated. But not this time. Waste of magnetic dots on a platter this time.)If you have 30 files to run, I don't see copying those into a single file as being a realistic option. Too cumbersome to copy-paste.A batch file that runs the files in order, using sqlcmd, is probably the best bet in that case.Are you in a position where you can take over a test server, run the scripts (by batch file or otherwise), and do a before/after check? If so, set up a test server just like the server you will eventually run the scripts on, back everything on it up, and run the scripts. Then you can fix/tweek them if they throw errors, then retore the test server and run them again.Rinse ... repeat ...Once they run without error, then compare what you end up with against your expected end result, and you'll know pretty well what to expect from your go-live.If you can't test before-hand in that manner, just assume the whole thing will blow up in production, and go from there. Have triage and emergency crews on-hand, expect problems, and make sure you have restorable backups before you run it. Plan for about 10 times the downtime that would be reasonable. Sometimes you just have do a "damn the torpedoes, full speed ahead" type thing, and make sure your damage-control team is on the ball. But avoid that if you can at all do so, and do a dry-run on a test server.Tue, 15 Jan 2013 14:17:41 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxHaha.... I made the effort to read some of Mr Celko's previous posts sometime ago... Lol he really lets loose sometimes but you know he does make some valid points. It's just his style is so damn rude!!Take it wth a shovel of salt. :-DAnyway, as GSquared said, GO is not a TSQL command, it's just a word that SSMS uses to know that you want to send a bunch of code in one batch.You say you have 30 scripts and some are dependent on others then you must also know the order the must run yes?If so then why notA) open new .sql file, copy and paste content of the first script, add a GO then paste in the second script and so on.b) schedule a sql agent job and place each script in its own step.C) create SSIS package with as a series of execute TSQL componentsD) batch fileThanks.Tue, 15 Jan 2013 13:39:35 GMTAbu Dinahttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxAgreed. Not everyone is obsessed with ISO standards.Tue, 15 Jan 2013 13:18:50 GMTEd Wagnerhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxI'd recommend using the SSIS as a previous poster recommended, allowing you to run each SQL file individually.I also recommend someone to stop pissing in Celko's cheerios. Damn that was harsh.Tue, 15 Jan 2013 13:10:36 GMTsqlPirate_Flhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxI agree with GSquared - combine things logically into groups. I've had deployment scripts of several thousand lines that I've run to release things to production before. When something gets really big, I have a master SQL file where I reference the other SQL files to run in order. When deployment time arrives, I simply follow the instructions I've written for myself. If I've practiced properly (run through it in order in test) then there shouldn't be any problems.Good luck with your big deployment.Tue, 15 Jan 2013 12:45:08 GMTEd Wagnerhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspx[quote][b]CELKO[/b] You do not know how to program in SQL to the point you are danger to your employer and the public. Please think about that. [/quote]Joe, you do not know how to read and interpret a question. The OP was not asking how to improve the function, nor was there anything in there remotely asking for your opinion. Do you really think the use of a UDF qualifies someone as a "danger" to the public at large? And if your nostalgia is so easily coerced by simple things like @i, why don't you find a FORTRAN or COBOL forum to annoy, where you can re-live your presently irrelevant glory days?Tue, 15 Jan 2013 11:45:50 GMTGreg Snidowhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxlol. CELKO. Easy there. Not only is this not my code but there’s darn near 200,000 lines of it across 30 scripts that will have to run next week. I can’t make changes to the scripts themselves w/o having to send it though QA again. No Can Do. This code is a run once set that after completion will be trashed. It’s part of a process that will move data from one place to another. Actually it is one small step in a much larger process. All of which I will be managing. When I’m done the new db will be created and loaded w/ 4.7 terabytes of data. To be honest I just grabbed the first thing I saw in the first file I clicked on and put it in the ticket. I’ve never actually seen that function before. As I mentioned before I don’t have the time nor testing cycles to rewrite what was written. However I do find it compelling that u would make such assumption and feel it is you place in this world to spew that nonsense on others. As if we are privileged to hear that dribble. Perhaps I should have made myself more clear in my original post and then you wouldn’t have made so many illogical assumptions. I don’t know. What I do know is someone needs a girlfriend or woman rather. Hit me up. I’m buyin because u my friend are treading on a very fine line. Please think about that.Tue, 15 Jan 2013 11:40:35 GMTSnargableshttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspx[quote] I have a manual process where I have, say, 30 scripts. Each one is dropping and creating all sorts of different SQL objects, functions, tables, indexes, etc. [/quote]This is the worst possible way to use SQL. The RDBMS model is based on logic; logic has “Universe of Discourse” (Google it!). But your mindset has a magical world in which things drop out of the sky. You put the “udf_” prefix on function names! Back in the days of FORTRAN II, the compilers were simple one-pass tools that used a first letter between 'I' and 'N' to signal the software that the variable was an Integer! You even used “DECLARE @i INTEGER” and almost made me cry from nostalgia. I had 1960's FORTRAN flashbacks! Local variables are not used in declarative languages like SQL. We nest expressions. Today, in 2013, we use ISO-11179 rules that give us “<verb>_<object>” names for procedures without compiler prefixes and the few (less than five in your entire career) functions. We also hate UDFs! They are how an old 1970's procedural programmer would write his FORTRAN or COBOL code. An SQL programer knows that they do not perform well, they are not relational and they are a bitch to maintain. Then you did the classic “VARCHAR(50)” (from ACCESS programming!) and local variables (from 1950's FORTRAN and Assembly language programming). And WHILE loops in a declarative language! Why do you think “@data” is a clear, precise data element name? What you did write can be replaced by a simple predicate: CHECK(something_name LIKE '[0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z] .. [0-9A-Z])You do not know how to program in SQL to the point you are danger to your employer and the public. Please think about that. Tue, 15 Jan 2013 11:13:50 GMTCELKOhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxSSIS package? Have a table with list of .sql files to run and have a loop container to run each?Tue, 15 Jan 2013 10:28:33 GMTWant a cool Sighttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxGO is a batch separator, not a T-SQL command, so it really doesn't work that way. That's why you can change to something other than "GO" in your SSMS preferences, but you can't change something like "SELECT" there.I'm used to combining scripts and building in the necessary error handling. Makes it a lot easier to manage the whole thing when I'm ready to migrate from my dev environment to my test environment, and then again to production, if it's one file. Can't accidentally run the third file second that way, or anything like that.Tue, 15 Jan 2013 10:01:21 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxi suppose i could use sql cmdshell to call a .sql file and put them in sequencial steps in a job. That would also allow for me to track runtime and if it failed or succededTue, 15 Jan 2013 09:19:03 GMTSnargableshttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxi suppose i could if i had to however some of them are dependent. So, I'd have to modify the contents or add some sort of try catch or error logic. These scripts are several thousand lines long and extremely complex. i was hoping i could just call each .sql file somehow and wrap the error logic around each call. Something along those lines. I don’t really have time to modify the contents of these scripts not the testing cycles. I would have thought that sql 2008 would have designed a way to wrap strips w/ GO in them.Tue, 15 Jan 2013 09:17:07 GMTSnargableshttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxWhy don't you just combine all the scripts into a single file? Then you just add GO where needed and it can all run at once.Tue, 15 Jan 2013 08:56:10 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1407304-392-1.aspxTo keep this simple i'm going to include an example however there are actually several scripts that i need to do this to. I have a manual process where i have, say, 30 scripts. Each one is dropping and creating all sorts of different sql objects. functions, tables, indexes, etc.I want to be able to execute these scripts as a chunk. Like wrap each script in a stored proc. My problem is i need the "GO" in each to separate the if exists drop and create. Is there another way for me to wrap these scripts so i can make one call and the scripts runs?Please advise if u have any questions. For some reason i dont feel i'm explaining it very well.For example. Is there something i can wrap the below in so i make one call?SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOIF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[udf_GetCleanUsername]') AND type in (N'FN', N'IF', N'TF', N'FS', N'FT')) DROP FUNCTION [dbo].[udf_GetCleanUsername]goCREATE FUNCTION [dbo].[udf_GetCleanUsername] (@Data VarChar(50))Returns VarChar(50)AsBegin Declare @Temp VarChar(50) Declare @i Integer Declare @Output VarChar(50) Set @i = 1 Set @Output = '' While @i <= Len(@Data) Begin Set @Temp = SubString(@Data, @i, 1) If @Temp IN ('0','1','2','3','4','5','6','7','8','9') OR @Temp IN ('A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z') Set @Output = @Output + @Temp Set @i = @i + 1 End Return (Select @Output)EndTue, 15 Jan 2013 08:44:26 GMTSnargables