Related
I'm working with an SSIS 2005 file that crashes Visual Studio 2005 on my workstation. This happens when I open the data flow diagram and Visual Studio attempts to validate the package. I can open it successfully on another computer though. The package itself is fairly simple and only has two control flow tasks and maybe ten tasks in the data flow.
I'm wondering if there is a tool that goes through the XML in the dtsx file and repairs any issues or if this is even necessary. The dtsx file is about 171 kB and it seems like there's a lot in it considering what a simple package it is.
I've had the same problem with a seemingly corrupt package crashing VS. Trying to analyze the xml directly is pretty painful, so through process of elimination, you might fix issues by doing things like moving one object in and out of a container, as this seems to fix issues with orphan references in the dtsx.
The "big red button" option is to recreate the package, which is less arduous than it sounds: you can just copy paste components between two VS sessions and you'll maybe discover the container causing the problem this way.
There's no tool to automate this unfortunately: SSIS is just an unfinished and quirky product.
I've only been using SSIS briefly, but I find that my complaints are numerous. Here are my current issues:
In order for a package to store a password, you need to encrypt it. Even if the package is part of a larger solution, you need to supply a password anytime to open any of the encrypted packages. Why can't you just encrypt the whole solution with one password? I have a solution with 10 encrypted packages. When I hit "Build", I have to enter 10 passwords.
Encrypting credentials is great. Deploying an encrypted package to the server, supplying your password, testing it successfully, scheduling it, and then having it fail during the schedule because it can't decrypt itself SUCKS. It seems to randomly do this, and I have redeployed a given package several times before it is actually able to decrypt the package credentials successfully during a scheduled job.
Windows authentication only? Maybe this is a security feature, but it makes it a real pain in the butt to remotely manage the server. It basically forces me to use remote desktop. Does it really matter that I can't access SSIS when I have access directly to the DB Engine???
DTS Support. DTS was pretty ugly, but it worked, and was pretty straightforward. Why didn't they provide the DTS 2000 package designer WITH SSIS??? Now I need to go download it and install it with admin privileges.
UPSERTS??? I replicate some data to an external database, and upserting to that database is SUCH A PAIN. Why isn't this functionality built in? Why can't I just say "This is the key column. Update if exists, create if it doesn't".
Are these valid issues, or am I just to new to the product to know how to do things the right way?
Do others have the same issues, or other issues?
Are there easy alternatives to using SSIS?
The following links from #SQLServerSleuth might shed some light on the situation - a back and forth re: SSIS in 2005. Are you on SQL 2008, or still working with SQL 2005? This picture changed a bit in 2008.
SSIS' 15 Faults
SSIS: The backlash (1)
SSIS: The backlash (2)
SSIS: A response from Microsoft to some growing criticism
In my system it was overall easier to just develop data loads in C#. The loads are rock solid and do not change unless we want them to change, so we don't spend any more time after we are done with development.
Check out Package Configuration files for some of the security issues.
Do you actually need the encryption on each package? You can say no encryption storage if you aren't storing an ftp or other authentication passwords. Configuration files are also a good idea. I recommend www.pragmaticworks.com/products/Business-Intelligence/BIxpress/ BIExpress as it will create all the config files for you, log the crap out of your packages and provide awesome blow your socks off graphical reporting for next to nothing cost wise...
let me preface this by saying that SSIS sucks. it's a pain to work with, manage, and develop. While there are tools that make things better, these features should have been included from the start. let me also say, that I haven't found (and don't believe there currently exists) a better tool for scalable high performance data loads than SSIS.
1,2: set the package to "Don't Save Sensitive", and use either configurations, or "Set Values" inside whatever execution context you are using.
3: agreed, partially. browsing the package store would be nice through sql auth, but executing the package should absolutely not be allowed (under what context do you execute?)
You can always execute through the job.
4: not related to SSIS
besides, DTS is deprecated, and in most ways, considerably less flexible and harder to manage than even SSIS.
5: Upserts are admittedly trickier than they could be, but if done right, it can work flawlessly:
either use a lookup to determine whether you need to insert or update, and define your logic accordingly.
side note: seriously consider setting up a package template. if done right, you can alleviate many of these concerns from the start. I may need to publicly post my package template at some point.
We ran into many of the same issues, especially #5, so I agree these are valid. In general, I found SSIS to be a massive pain to work with.
For 1, 2, I use package configurations.
For 5 you can use a slowly changing dimension task or the third-party table difference component. I personally prefer to load to a staging table and code the UPSERT in SQL.
I've been using SSIS fairly intesively on a DW project for the last 2 years and I find it to have a few quirks but it is far more powerful than DTS.
I've been searching for some time for a good solution to implement the idea of managing schema on an SQL Server Compact 3.5 database.
I know of several ways of managing schema on SQL Server Express, SQL Server Standard, SQL Server Enterprise, but the Compact Edition doesn't support the necessary tools required to use the same methodology.
Any suggestions/tips?
I should expand this to say that it is for 100+ clients with wrapperware software. As the system changes, I need to publish update scripts alongside the new binaries to the client. I was looking for a decent method by which to publish this without having to just hand the client a script file and say "Run this in SSMSE". Most clients are not capable of doing such a beast.
A buddy of mine disclosed a partial script on how to handle the SQL Server piece of my task, but never worked on Compact Edition. It looks like I'll be on my own for this.
What I think that I've decided to do, and it's going to need a "geek week" to accomplish, is to write some sort of a tool much like how WiX and NAnt works, so that I can just write an overzealous XML document to handle the work.
If I think that it is worthwhile, I'll publish it on CodePlex and/or The Code Project because I've used both sites a bit to gain better understanding of concepts for jobs I've done in the past, and I think it is probably worthwhile to give back a little.
Edit on 5/3/2010:
If someone is willing to "name" the project, I'll upload the dirty/nasty version that I've written for MS SQL to CodePlex so that maybe we can start hacking out a version of SQL Compact. Although, I think with the next revision of the initial application that I was planning, I'm going to be abandoning SQL Compact and just use XML Files for storage, as the software is being converted from an Installable package to being a Silverlight application. Silverlight just gives a better access strategy.
I am currently looking into Migrator.Net.
This allows you to write changes to your database, called migrations, directly in C#.
These migrations can contain everything from simple table additions/drops, column modifications, to complicated data update code.
When your application boots, it can verify what version the database is currently in and apply any migrations that are required to bring it up to date. All this is handled automatically. The code to run this update is as simple as:
Assembly asm = Assembly.Load("LocalModels.migration");
Migrator m = new Migrator("SqlServerCe", "Data Source=LocalModels.sdf", asm, false);
m.MigrateToLastVersion();
I am having a couple minor issues with the Compact support (it assumes the default schema is dbo). But I don't think it will be too difficult to fix them.
some random thoughts (not sure I can fully answer though)
the Microsoft Sync Framework is one option. I haven't had a chance to fully appreciate what it can do once you've deployed it after the initial first time (which seems to work fine). There's a MSDN site for it here
You can execute scripts on a mobile device, but not through something like SQL Management Studio, so in theory you could manage/maintain T-SQL scripts but the down side is that the T-SQL would be convoluted (to CE's supported statements) and I don't know a way to "automate" execution - but the Sync Framework might hold some answers..
If one of your key criteria is going to be working efficiently over a small pipe, the only real choice you have is to store a DB Schema Version (maybe somehow tied to the scripts checked into your CMS) and when an update is needed, the change scripts are sent over the wire and applied in order. You would probably want to keep a log in your DB as well of these scripts being applied so you can gracefully handle disconnects, reboots and other potentially nasty problems.
Is SQL Server Management Studio any use for you?
http://technet.microsoft.com/en-us/library/ms172933.aspx
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm currently using Toad for my day-to-day work on our databases (queries, updates, small scripts, browsing of db objects, etc.).
My question is: since my version of Toad is old and buggy, which are the (possibly free, but not necessarily) alternatives to Toad?
The database versions we are using are 10g and 9i.
Thanks a lot.
Oracle's SQL Developer.
PL/SQL Developer from http://www.allroundautomations.nl/. Presented between a choice between Toad and PL/SQL developer, about half the developers prefer PL/SQL developer. I have to admit the code completion in PL/SQL developer is much better, but I still prefer Toad for the DBMS management functionality.
TOra is an another good option. I used the pre GPL version for years. It's a good simple SQL tool for Oracle.
It supports schema browsing, analyse plan, limited debugging plus all the stuff you'd expect.
I've used Squirrel-SQL (which is a Java/JDBC based program and will work with any OS or database that provides a driver) and the database development tools for Eclipse (Eclipse-DTP). Both are certainly sufficient for light database work. Both are free and open-source.
After trying other products for some months, I'm back to Toad.
And I have to admit that (IMHO, and for the type of use that I'm doing of it): I've found no alternative to Toad.
The indispensable features that are missing in other products are:
Speed. Toad is blazingly fast; SQL Developer starts to crawl if you open more than 2 or 3 connections. When you have to operate with time constraints, you really can't wait SQL Developer to open.
The "open a new window until commit" functionality (a new window is opened after an insert or update statement, and you are forced to commit or rollback). Really handy to avoid pending commits.
The "execute current statement" functionality (shift-F9). SQL Developer doesn't have it, or you are forced to select the query you want to execute.
I'm surprised that nobody has mentioned DbVisualizer yet. Our company has been using it for a few years and everybody seems happy with it. It's powerful, runs on multiple platforms (Java-based) and supports different database systems (Oracle, DB2, MS Access etc). It has a free version; a commercial version is available if you need more features.
Simple answer:
Use Textpad or another text editor.
Explanation:
For me PL/SQL development is a process that has evolved over time. I've tried to apply continuous improvement to SQL development and it has worked out wonderfully for me. (for more on continuous improvement/Kaizen see link text)
I found PL/SQL IDE tools to be unstable.
I've had several crashes of Quest Software's TOAD as well as Quest Software's SQL Navigator (I've been using it since Version 3).
I lost work.
I tried other IDE PL/SQL tools.
These tools also crashed.
I lost work again.
I got frustrated.
I do not trust PL/SQL software development to any of the PL/SQL IDE tools out there.
Here are my PL/SQL coding core practices:
1. Export code using Quest Software TOAD
2. Use a Cygwin bash script to move files into the appropriate directories
3. Compare versions via BeyondCompare (if needed)
4. Check code out of WinCVS / CVSNT (if needed)
5. Edit using TextPad
6. Compare versions via BeyondCompare (if needed)
7. Check code in to WinCVS / CVSNT (if needed)
8. Use a Cygwin bash script to create a master changes file.
9. Import code back using Quest Software TOAD
An even more lengthy explanation:
I use Quest Software TOAD to export all PL/SQL and table DDL code to the filesystem.
In the Database menu -> Export -> Source Code
In the Database menu -> Export -> Table Scripts
This gets me individual files for each database object.
I move these files (Cygwin bash script) in directories
based on the file extensions.
*.prc files in /procedures
*.fnc files in /functions
*.pks and *.pkb files in /proceudres
*.trg files in /triggers
*.vw files in /views
*.sql files in /table_scripts
These files are initially checked into CVS.
(I use WinCVS/CVSNT server side)
I Beyond Compare each file version exported by TOAD
with the version already in CVS.
I ensure that the CVS sql repository is up to date.
In other words I need to have a good starting baseline.
I then use TextPad to edit the PL/SQL code.
link text
I pre-configure my Textpad with SQL syntax files
to make it easier on the eyes
link text
After editing, I Beyond Compare each edited
file version exported with the version
in WinCVS.
Luckily, WinCVS allows you to use an external
diff (Beyond Compare) which comes in very handy.
I load the new/changed code via TOAD to a test schema.
In the SQL Editor menu -> Load and Execute a Script File
I test the code out. (do some debug runs)
If the code tests out, I check the code into CVS.
At the end, I use Cygwin bash (and a bash script I've written) to create a master changes file. This master changes file contains all of the changes that need to be applied to bring the live schema up to date. This saves me a lot of time.
I then load the new/changed code via TOAD to a live schema. In the SQL Editor menu -> Load and Execute a Script File. That's about it. Software engineering is about process, versioning (CVS) and automating builds (bash script).
The biggest lesson out of all this (that have made me 10 times more productive) was switching from DB-based PL/SQL IDEs to simple ASCII text files. KIS in action.
If a copy your code resides in an ASCII file you avoid:
- mucking up the DB
- locking up DB objects
- iffy DB based revision control tools (if any)
- iffy DB diff tools (if any)
- losing code due to IDE crashes
- losing code due to DB crashes / shutdowns
- losing code due to concurrent editing (this can happen if two or more PL/SQL developers edit the same procedure)
Instead if you handle all PL/SQL code in filesystem ASCII files you have
- your choice of text editors (TextPad,notepad++,vi,etc)
- your choice of revision control systems (CVS,svn)
- your choice of text filtering/handling/scripting systems (I like Cygwin bash)
- your choice of diff tools (Beyond Compare,WinDiff,diff)
- your choice of DB tools (I can use TOAD, SQL Navigator) for importing and exporting the PL/SQL code to files.
I wanted a version history of all code changes.
I wanted to get everyone working together and prevent developers from stepping on each other's toes.
I wanted the freedom to choose my tools.
The side effect of this is that I handle all of the DB code in the filesystem during rapid development.
Just my 2 cents.
I'll toss in my vote for SQLPal. It's free. Most of the features it has works really well (auto-competition has never seemed to work). I'm using it against a 10g database daily and it works great.
I've been using Golden from Benthic Software as a SQL*Plus replacement for a long time and love it.
http://www.benthicsoftware.com/products.htm
If we had to pay then I would strongly recommend PL/SQL Developer for database code writting and TOAD for administration tasks.
From the free solutions I've been using so far especially four of them: (Oracle) SQL Developer, SQL Tools, SQLPal and TORA.
I've found SQL Developer as the one with the most utilities.
Unfortunately its java GUI makes it prone to hanging too much often.
SQL Tools is a very nice instrument except one thing: it has not an
auto-fill functionality / code-completion (e.g. table names and columns). If you could
pass this issue then ... go for it.
SQLPal it's good as long as you have to look at only one database
object at time. I just don't understand why displaying a simply
new window is, in fapt, meaning to open a completely new instance
of the application. It has its auto-fill functionality but that makes it very laggy. I would place a minus for its JDBC only available connection option. Such limitation makes it sometimes to hang while waiting to retrieve database metadictionay information.
TORA - it's a nice tool except the code completion ... I just couldn't make it working. And from the forums I could get that this is a pretty common problem. Otherwise its GUI is
almost flawless.
My conclusion: I hate to say it, I am an open-source fan but ... simply buy PL/SQL Developer / TOAD if you have to work intensively with such tools .
I would also recommend Oracle's SQL Developer, however I've found WinSQL to be quite good as well. SQL Developer is free and WinSQL has a community version that is quite robust, and works well against other platforms too (I also use it for working with Netezza).
I've used OraDeveloper by DevArt to connect to Oracle databases. It's nice because it plugs into Visual Studio in much the same way as the SQL Server databases can be queried through Server Explorer. It is not free, but in our case it came free with the purchase of OraDirect .Net, which is a new provider that allows Oracle to work with Microsoft's Entity Framework.
Having done 3 years in one job using TOAD, and now 5 years in current job using PL/SQL Developer, I would say overall TOAD is a better tool, but if you are specifically developing stored procedures in PL/SQL, PL/SQL Developer is better.
Don't forget get to set up the context sensitive help (under Help - HTML Manuals)
You could also use sqltools, which some of my colleagues prefer. I never got used to it, but looks powerful.
I use PL/SQL Developer for running multiple queries and stored procedure development, as it's rock solid, and you can kill the process via Task Manager, and get back all your windows upon starting up again.
I use TOAD for browsing, as that functionality can't be beat. But it's flaky on me, hanging, etc, although that is probably my computer..
I would buy both. I have both open now.
For accessing odd sources (OSISoft PI, JDE on AS400, 4D, Access, Excel), I use Advanced Query Tool. It's great to be able to use SQL against an Excel sheet of a proposed table, to create your DDL.
I love Toad. I had to switch to Embarcadero's Rapid SQL for two months and it damn near killed me. So while I don't know of any products that are better than Toad, I can say without reservation that Rapid SQL is wholly inadequate.
We are using RazorSQL for Oracle and also DB2. It is low cost and has a ton of features.
PLSQL Developer very good for Oracle DBMS, specifically for Stored Proc, but not so well for the DBMS management.
Just to throw it out there - did you know you can grab the beta of Toad 4.1 and use that for free? The betas are always free to the public.
I've used Embarcadero DBArtisan (not free)
I thought it was good.
I second the SQL Developer comments. FWIW, the newer versions of Toad are much more stable than the golden oldies were. I'm using Toad 9.7 and it's quite good.
I'm using PL/SQL Developer, which I think one of the best oracle database tools, it's lite and fast, I have one copy in my USB flash to allow me to use it in any pc(you just copy it from the program files folder and place it in the flash and it will work fine).
Also I bought OraDeveloper from DevArt three months ago, it's has some good features, but it's slower than PL/SQL Developer and require .Net framekwork. but the good thing that it has direct connection to Oracle, so you can use it from any PC without requiring Oracle client to be installed.
Another tools is EMS SQL Management Studio for Oracle, which looks nice, and have some nice features specially with import/export from other format.
http://sqlmanager.net/en/products/studio/oracle
and for free one you can use AnySQL Maestro, which has support for Oracle/MySql/Sql server and offer AnySql Maestro for free
http://www.sqlmaestro.com/
I've tried most of the tools suggested above, and found that I prefer this one over all of them (including TOAD):
SQLDetective
SQL Studio for Oracle is really nice...
Dreamcoder offers good set of tools for Database Management.
I prefer both Toad or SQL Developer. But I give more preference to Toad because of features like-
If you want to update your select result in toad, just add the ROWID
is your select statement. Once you select the records with ROWID then
you can edit/update your result grid.
Also, the session and Database monitoring monitoring features are much better in Toad. The only downside of Toad is that it requires Oracle SQL Client to be installed (which may be the case with any other non-Oracle branded tool), on the other hand Oracle SQL Client installation is not necessary for SQL Developer.
Worked with PL/SQL developer. It rocks.
I wonder how you guys manage deployment of a database between 2 SQL Servers, specifically SQL Server 2005.
Now, there is a development and a live one. As this should be part of a buildscript (standard windows batch, even do with current complexity of those scripts, i might switch to PowerShell or so later), Enterprise Manager/Management Studio Express do not count.
Would you just copy the .mdf File and attach it? I am always a bit careful when working with binary data, as this seems to be a compatiblity issue (even though development and live should run the same version of the server at all time).
Or - given the lack of "EXPLAIN CREATE TABLE" in T-SQL - do you do something that exports an existing database into SQL-Scripts which you can run on the target server? If yes, is there a tool that can automatically dump a given Database into SQL Queries and that runs off the command line? (Again, Enterprise Manager/Management Studio Express do not count).
And lastly - given the fact that the live database already contains data, the deployment may not involve creating all tables but rather checking the difference in structure and ALTER TABLE the live ones instead, which may also need data verification/conversion when existing fields change.
Now, i hear a lot of great stuff about the Red Gate products, but for hobby projects, the price is a bit steep.
So, what are you using to automatically deploy SQL Server Databases from Test to Live?
I've taken to hand-coding all of my DDL (creates/alter/delete) statements, adding them to my .sln as text files, and using normal versioning (using subversion, but any revision control should work). This way, I not only get the benefit of versioning, but updating live from dev/stage is the same process for code and database - tags, branches and so on work all the same.
Otherwise, I agree redgate is expensive if you don't have a company buying it for you. If you can get a company to buy it for you though, it really is worth it!
For my projects I alternate between SQL Compare from REd Gate and the Database Publishing Wizard from Microsoft which you can download free
here.
The Wizard isn't as slick as SQL Compare or SQL Data Compare but it does the trick. One issue is that the scripts it generates may need some rearranging and/or editing to flow in one shot.
On the up side, it can move your schema and data which isn't bad for a free tool.
Don't forget Microsoft's solution to the problem: Visual Studio 2008 Database Edition. Includes tools for deploying changes to databases, producing a diff between databases for schema and/or data changes, unit tests, test data generation.
It's pretty expensive but I used the trial edition for a while and thought it was brilliant. It makes the database as easy to work with as any other piece of code.
Like Rob Allen, I use SQL Compare / Data Compare by Redgate. I also use the Database publishing wizard by Microsoft. I also have a console app I wrote in C# that takes a sql script and runs it on a server. This way you can run large scripts with 'GO' commands in it from a command line or in a batch script.
I use Microsoft.SqlServer.BatchParser.dll and Microsoft.SqlServer.ConnectionInfo.dll libraries in the console application.
I work the same way Karl does, by keeping all of my SQL scripts for creating and altering tables in a text file that I keep in source control. In fact, to avoid the problem of having to have a script examine the live database to determine what ALTERs to run, I usually work like this:
On the first version, I place everything during testing into one SQL script, and treat all tables as a CREATE. This means I end up dropping and readding tables a lot during testing, but that's not a big deal early into the project (since I'm usually hacking the data I'm using at that point anyway).
On all subsequent versions, I do two things: I make a new text file to hold the upgrade SQL scripts, that contain just the ALTERs for that version. And I make the changes to the original, create a fresh database script as well. This way an upgrade just runs the upgrade script, but if we have to recreate the DB we don't need to run 100 scripts to get there.
Depending on how I'm deploying the DB changes, I'll also usually put a version table in the DB that holds the version of the DB. Then, rather than make any human decisions about which scripts to run, whatever code I have running the create/upgrade scripts uses the version to determine what to run.
The one thing this will not do is help if part of what you're moving from test to production is data, but if you want to manage structure and not pay for a nice, but expensive DB management package, is really not very difficult. I've also found it's a pretty good way of keeping mental track of your DB.
If you have a company buying it, Toad from Quest Software has this kind of management functionality built in. It's basically a two-click operation to compare two schemas and generate a sync script from one to the other.
They have editions for most of the popular databases, including of course Sql Server.
I agree that scripting everything is the best way to go and is what I advocate at work. You should script everything from DB and object creation to populating your lookup tables.
Anything you do in UI only won't translate (especially for changes... not so much for first deployments) and will end up requiring a tools like what Redgate offers.
Using SMO/DMO, it isn't too difficult to generate a script of your schema. Data is a little more fun, but still doable.
In general, I take "Script It" approach, but you might want to consider something along these lines:
Distinguish between Development and Staging, such that you can Develop with a subset of data ... this I would create a tool to simply pull down some production data, or generate fake data where security is concerned.
For team development, each change to the database will have to be coordinated amongst your team members. Schema and data changes can be intermingled, but a single script should enable a given feature. Once all your features are ready, you bundle these up in a single SQL file and run that against a restore of production.
Once your staging has cleared acceptance, you run the single SQL file again on the production machine.
I have used the Red Gate tools and they are great tools, but if you can't afford it, building the tools and working this way isn't too far from the ideal.
I'm using Subsonic's migrations mechanism so I just have a dll with classes in squential order that have 2 methods, up and down. There is a continuous integration/build script hook into nant, so that I can automate the upgrading of my database.
Its not the best thign in the world, but it beats writing DDL.
RedGate SqlCompare is a way to go in my opinion. We do DB deployment on a regular basis and since I started using that tool I have never looked back.
Very intuitive interface and saves a lot of time in the end.
The Pro version will take care of scripting for the source control integration as well.
I also maintain scripts for all my objects and data. For deploying I wrote this free utility - http://www.sqldart.com. It'll let you reorder your script files and will run the whole lot within a transaction.
I agree with keeping everything in source control and manually scripting all changes. Changes to the schema for a single release go into a script file created specifically for that release. All stored procs, views, etc should go into individual files and treated just like .cs or .aspx as far as source control goes. I use a powershell script to generate one big .sql file for updating the programmability stuff.
I don't like automating the application of schema changes, like new tables, new columns, etc. When doing a production release, I like to go through the change script command by command to make sure each one works as expected. There's nothing worse than running a big change script on production and getting errors because you forgot some little detail that didn't present itself in development.
I have also learned that indexes need to be treated just like code files and put into source control.
And you should definitely have more than 2 databases - dev and live. You should have a dev database that everybody uses for daily dev tasks. Then a staging database that mimics production and is used to do your integration testing. Then maybe a complete recent copy of production (restored from a full backup), if that is feasible, so your last round of installation testing goes against something that is as close to the real thing as possible.
I do all my database creation as DDL and then wrap that DDL into a schema maintainence class. I may do various things to create the DDL in the first place but fundamentally I do all the schema maint in code. This also means that if one needs to do non DDL things that don't map well to SQL you can write procedural logic and run it between lumps of DDL/DML.
My dbs then have a table which defines the current version so one can code a relatively straightforward set of tests:
Does the DB exist? If not create it.
Is the DB the current version? If not then run the methods, in sequence, that bring the schema up to date (you may want to prompt the user to confirm and - ideally - do backups at this point).
For a single user app I just run this in place, for a web app we currently to lock the user out if the versions don't match and have a stand alone schema maint app we run. For multi-user it will depend on the particular environment.
The advantage? Well I have a very high level of confidence that the schema for the apps that use this methodology is consistent across all instances of those applications. Its not perfect, there are issues, but it works...
There are some issues when developing in a team environment but that's more or less a given anyway!
Murph
I'm currently working the same thing to you. Not only deploying SQL Server databases from test to live but also include the whole process from Local -> Integration -> Test -> Production. So what can make me easily everyday is I do NAnt task with Red-Gate SQL Compare. I'm not working for RedGate but I have to say it is good choice.