Ok, so I've got a bit of a SQL and Powershell problem. There are 2 SQL scripts, one to setup 4 different global stored procedures. Another to execute them and manipulate data before returning it to PS to be placed in a CSV file. The reason I'm not putting them into a single file is for readability. The procs are enclosing huge chunks of sql and I cannot create permanent procs in our production environment.
The problem I'm running into is the script runs fine in SQL Mgmt Studio but when ran by PS, I get several errors around the 'go's in the script.
I'm pretty sure this is a problem with the format that PS and the .NET classes expect when executing and returning data sets but...I'm at a loss.
I'm running SQL Server 2005 btw.
Any ideas or similar experiences?
What errors do you get? How are you executing each file? GO is a batch separator understood only by certain tools (e.g. Management Studio); PowerShell doesn't know what GO means. Have you tried executing the separate CREATE PROCEDURE scripts without issuing a GO command between them? If they are separate commands this shouldn't be an issue.
"GO" is a delimiter used by SQL Management Studio. It is not a valid SQL keyword. You can configure SQL Management Studio and change "GO" to "ENGAGE" if you wanted to.
Just remove "GO" from the scripts.
Related
The build process for my SQL 2008 Database Project takes upwards of 15 minutes for 1 build. I only need to manage roughly 50 stored procedures. I created a database project and a server project.
Next thing I do is fix all the build errors. Now I modify a stored procedure. Then I have to build the entire database and script the entire database just to see if my stored procedure compiles.
Is there any way to test the stored procedure without going through a 15 minute build - then deploy the script? Can I build just changes instead of the entire DB?
First of all, you should look at why your builds take so long. Maybe you need more memory or something.
Second, why do you have to script the entire database to test the stored procedure? Just deploy to a test database, or even your local sandbox database.
I decided to go with MSSCCI. It's simple UI which plugs directly into SSMS and behaves like Team Explorer is exactly what I've been searching for. Getting started.
I've never used visual studios to "build" and maintain databases. This, I'd guess, will quickly become unmanageable as the database starts getting bigger. And I'm assuming when you "build" it, it's verifying and deploying all objects in the database.
I would suggest you do not use visual studios in this fashion. Just maintain your sql code independently. And store them in version control systems manually. That way you can update each stored procs separately. In other words, keep each stored proc as a file.
if object_id(<ProcName>) is not null
drop proc <ProcName>
GO
create proc <ProcName>
...
GO
Then, store that as ProcName.sql and let source control handle the rest. Sorry if this isn't helpful or if I'm just stating the obvious.
How can I execute SQL commands in Visual Studio Server Explorer?
When I right click a sql directory (like tables), I get the options:
Add new table
Compare data
Execute query
But I want to do none of these, what I want is an empty screen where I can type my command, and execute it.
I don't want to use "Execute query" for writing commands, because it's for writing "queries", not all commands.
Alright, this is a pretty retarded solution to this problem but I guess it's good enough for me. I downloaded SQL Managment Studio, and installed it. It comes with a handy "Ssms.exe" that's hidden somewhere in program files with which you can manage your db.
From SQL Server point of view; a "command" and a query is the same thing. It is evaluated by the same code in the server.
A "command" is a SQL server DDL (Data Definition Language). A query is a SQL server DML (Data Manipulation Language). In a SQL server command batch use can issue both DDL and DML.
The "New Query" button which will give you the behavior you are expecting is available by adding the menu through View > Toolbars > Transact-SQL Editor
I'm looking for a way to copy stored procedures from one sql database to another on the same instance. It needs to be automatic, preferably through code (t-sql or anything), so using the generate scripts trick is not viable (plus I don't want to maintain that many scripts, and people forget to run them).
I've searched a bit on this and have not found a workable solution. Someone suggested a clever trick with generating all the stored procedure text into a sql field and then converting that and executing it on the destination db but unfortunately that had issues.
Has anyone got any other ideas on how this can be done, if it's at all possible?
If I can't do it programmatically, would there be a quick solution using ssis?
Thanks.
Edit: Using mixture of sql 2005 and 2008 versions.
You can do it programatically in .NET using the SMO framework.
Free/easy implementation could be done via PowerShell.
I have a script that does just this - it generates the scripts for SQL objects, including Stored Procs, and executes the creation scripts on the target server.
It's a handy workaround when security concerns don't allow linked servers but you need to keep certain resources in sync across multiple servers.
If all you care about are the procs, it should be fairly straightforward to check sys.sql_modules on your source and target DBs and execute any that don't exist in the target via the definition field in that view.
How can I move a db from one server to another (I only have access to the database with mylittleadmin). Like the title says, I guess the "easiest" way would be by generating SQL with a stored procedure.
I'm using SQL Server 2008 on both servers.
In the codeplex project Extreme T-SQL Script I have written T-SQL procedures to script the content of tables. I just abandoned its use myself in favor of ssms tools pack, but the later is no option for you.
When using these procedures in SSMS or VS the main problem is that Microsoft has limits on max column width and max length of output from Print-Statements.
I can't predict, which such limits exist when using mylittleadmin.
It depends on which datatypes and which varchar length you are using. Writing scripts that handle special needs is possible.
Further you need something to script the database objects first and it might be difficult to find something for that, as most people just use SSMS for this purpose. sp_helptext might help to script procedures.
In SSMS, you have the ability to copy or move a database from one instance of SQL Server to another. You can right-click on the database in SSMS, choose Tasks and then Copy Database...
Or, of course, you can simply backup the DB and restore on your target server.
(I have no idea what 'myLitleAdmin' is that you referred to)
You dont need to make a stored procedure. The easiest way to do it is by right click on your database -->task-->back up and create a backup.
after that you can restore your database on the other server.
If you have a license for myLittleAdmin then do as their web states. It says
"Purchasing a license gives you unlimited mail support.
Send your request at support#mylittletools.net"
Actually I found out that you could make a backup of the database in myLittleAdmin. The resulting .bak file was then emailed to me as a link.
Thanks for the comments though, voted up some of them :)
Is it possible to restore a backup of a SQL Server 2008 database onto an instance of SQL Server 2005?
I need to work on an sample application for which database backup is in sql server 2008.
But I'll not be able to install 2008. So is it possible to restore that back up in 2005?
No. It is not possible to restore a database from a backup of a newer version.
If you are dead set on it, I think your best option is to selet the database in the Object Explorer in SQL 2008,
right-click, select Tasks->Generate Scripts.In the options dialog emable about everything, including Script Data.
And make sure you select "Script for SQL 2005".
Source
When importing the objects into your target server, if the objects are large you may find that you can't open the SQL file via Management Studio (with a completely useless "The operation could not be completed" error, no less). That's okay, just load the file via sqlcmd.
One important thing is missing in all answers and that is the fact that Generate Scripts in SSMS doesn’t order the scripts correctly.
Scripts have to be ordered in the correct dependency order so that child tables are created after parent tables and such.
This is not an issue for small databases where its easy to reorder the scripts manually but it can be a huge issue when dealing with databases that have 100+ objects.
My experience is that its most convenient to use third party tools that can read backup and generate scripts in the correct order. I’m using ApexSQL Diff and Data Diff from ApexSQL but you can’t go wrong with any popular vendor.
No, not directly. SQL Server 2008 database backups are not backward compatible with SQL Server 2005. However, with SQL Server 2008 Management Studio, you can script data and schemas in SQL Server 2005 mode. This article describes the process in detail.
Yes it is possible
Using the export in the SQL Server 2008. Go to All Programs --> Microsoft SQL Server 2008 --> Import and Export Data
Then SQL Server Import AND Export Wizard window will be opened. Press Next
Choose a Data source (in your case from SQL Server 2008). Choose a Destination( in your case from SQL Server 2005).
Select Copy data from one or more tables or view
Select the source's tables and destination's tables
Click Next & Finish
to complete.
I have had this problem for a long while.
You cannot restore SQL2008 backups onto an SQL2005 instance.
And for me, workarounds like import/export wizzard or to script the database from SQL2008 using the generate scripts with the for SQL2005 option won't work.
Because simply, my databases cross-reference each other inside their views and stored procedures or udfs. They do not befall to my responsibility completely and so I cannot consolidate them into 1 database.
They are a set of 6 dbs that refer to each other directly inside their views and stored procedures.
When I transfer them from one SQL2005 instance onto another, I usually do full-backup/restore.
If I were to script them, even with the with dependencies option I would get errors at re-creation time as db1 will not find views inside db3 because it so happened that I executed the create db1 script first. If I tried db3 first I get similar exceptions.
The only way to script them so that I won't have such dependency exceptions, is to figure out a sequence that works and script them partially in that manner: say: db1_tables followed by db2_tables followed by db2_views followed by db1_views, sp, udfs etc.
I have such a sequence. And when I need to create a new set of such 6 dbs, I executed the smaller partial scripts in sequence.
This explains why the generate scripts, with dependencies and with data and set to SQL2005 version scripts, will just not work for me.
The import/export wizzard is better in my case because it will copy tables and then you still have to script all views, sp, udfs etc.
What I really need is a conversion tool for SQL2008 backup files, to convert them to SQL2005 format. Then my problem will go away.
Or some kind of a tool that would allow restore from SQL2008 full-backup files, without asking me too many questions.
If anyone knows such tools and have used them, let me know.
You can use DBSave, it's a great freeware tool to backup and restore ms sql server on different machines.
It's verry simple to setup and to use.
No you can't, but tools like red gate's SQL Compare/Data Compare can read backup files directly & transfer the info across to a live database, dealing with any syntax or settings that aren't compatible on SS2005
Having had no luck with the Import/Export stuff (flat file exports failed on import claiming charset mapping issues [even though same charset used throughout] and/or truncation issues [even though source and destination had exact same structure]), and having had no luck with using the "generate scripts" option suggested by Garry Shutler (it generated a script with syntax errors), I was finally able to copy the big table I wanted to copy from 2008 to 2005 using the SQL Server bcp utility. So that's another option for this situation, although for an entire database it would be table-by-table and probably doesn't help with views and such.
The steps I used:
On the source server, use "Script Table As...CREATE" to get the structure, run that on the target server.
On the target server, create a bcp format file using your newly-created table:
bcp database.owner.table format nul -f table.fmt -n
(If you're not using Windows auth, you may need the -U and -P options to specify username and password.)
Copy that format file to the source server (if necessary).
Export the data to file on the source server:
bcp database.owner.table out table.dat -f table.fmt
(Again, possibly with -U and -P.)
Copy the data file to the target server (if necessary).
Import the data on the target server:
bcp database.owner.table in table.dat -f table.fmt
(Again, possibly with -U and -P.)
In hopes that proves useful to someone else.