Yes, I know. The existence of a running copy of SQL Server 6.5 in 2008 is absurd.
That stipulated, what is the best way to migrate from 6.5 to 2005? Is there any direct path? Most of the documentation I've found deals with upgrading 6.5 to 7.
Should I forget about the native SQL Server upgrade utilities, script out all of the objects and data, and try to recreate from scratch?
I was going to attempt the upgrade this weekend, but server issues pushed it back till next. So, any ideas would be welcomed during the course of the week.
Update. This is how I ended up doing it:
Back up the database in question and Master on 6.5.
Execute SQL Server 2000's instcat.sql against 6.5's Master. This allows SQL Server 2000's OLEDB provider to connect to 6.5.
Use SQL Server 2000's standalone "Import and Export Data" to create a DTS package, using OLEDB to connect to 6.5. This successfully copied all 6.5's tables to a new 2005 database (also using OLEDB).
Use 6.5's Enterprise Manager to script out all of the database's indexes and triggers to a .sql file.
Execute that .sql file against the new copy of the database, in 2005's Management Studio.
Use 6.5's Enterprise Manager to script out all of the stored procedures.
Execute that .sql file against the 2005 database. Several dozen sprocs had issues making them incompatible with 2005. Mainly non-ANSI joins and quoted identifier issues.
Corrected all of those issues and re-executed the .sql file.
Recreated the 6.5's logins in 2005 and gave them appropriate permissions.
There was a bit of rinse/repeat when correcting the stored procedures (there were hundreds of them to correct), but the upgrade went great otherwise.
Being able to use Management Studio instead of Query Analyzer and Enterprise Manager 6.5 is such an amazing difference. A few report queries that took 20-30 seconds on the 6.5 database are now running in 1-2 seconds, without any modification, new indexes, or anything. I didn't expect that kind of immediate improvement.
Hey, I'm still stuck in that camp too. The third party application we have to support is FINALLY going to 2K5, so we're almost out of the wood. But I feel your pain 8^D
That said, from everything I heard from our DBA, the key is to convert the database to 8.0 format first, and then go to 2005. I believe they used the built in migration/upgrade tools for this. There are some big steps between 6.5 and 8.0 that are better solved there than going from 6.5 to 2005 directly.
Your BIGGEST pain, if you didn't know already, is that DTS is gone in favor of SSIS. There is a shell type module that will run your existing DTS packages, but you're going to want to manually recreate them all in SSIS. Ease of this will depend on the complexity of the packages themselves, but I've done a few at work so far and they've been pretty smooth.
You can upgrade 6.5 to SQL Server 2000. You may have an easier time getting a hold of SQL Server or the 2000 version of the MSDE. Microsoft has a page on going from 6.5 to 2000. Once you have the database in 2000 format, SQL Server 2005 will have no trouble upgrading it to the 2005 format.
If you don't have SQL Server 2000, you can download the MSDE 2000 version directly from Microsoft.
I am by no means authoritative, but I believe the only supported path is from 6.5 to 7. Certainly that would be the most sane route, then I believe you can migrate from 7 directly to 2005 pretty painlessly.
As for scripting out all the objects - I would advise against it as you will inevitably miss something (unless your database is truly trivial).
If you can find a professional or some other super-enterprise version of Visual Studio 6.0 - it came with a copy of MSDE (Basically the predecessor to SQL Express). I believe MSDE 2000 is still available as a free download from Microsoft, but I don't know if you can migrate directly from 6.5 to 2000.
I think in concept, you won't likely face any danger. Years of practice however tell me that you will always miss some object, permission, or other database item that won't manifest itself immediately. If you can script out the entire dump, the better. As you will be less likely to miss something - and if you do miss something, it can be easily added to the script and fixed. I would avoid any manual steps (other than hitting the enter key once) like the plague.
Related
Regarding the following images, I have obviously installed the Microsoft SQL Server, but I can't find the exe-file or anything named Microsoft SQL Server in the start menu.
Anyone who knows what to do to solve this, or do I need to install something more?
SQL Server runs as a service. You can start and stop it from windows services. SSMS is a gui tool for managing ddl (creating and altering tables and index's for example) and dml (writing queries to inquire, update or add data to databases).SSMS comes free with every edition of SQL server - perhaps you didn't tick a box when installing? You can also do this stuff the old fashioned way using sqlcmd from command line(DBAs love this for some reason) but for us mortals SSMS is much less of a struggle. As an aside there are other guis such as Toad (expensive) and Heidisql (free) amongst others which will do the job.
Looks like you have the engine. What you've got to do now is install SQL Server Management Studio: https://msdn.microsoft.com/hr-hr/library/mt238290.aspx
Looks like you have the various SQL Server components that are installed by Visual Studio (recent version) or SQL Server Data Tools (as used by VS).
We have a simple console app that uses EF 4 to process data; read from one, do some stuff, insert into another database. In the EDMX file, ProviderManifestToken for the destination db is set to "2005".
Yesterday, our app blew up. To make a long story short, our consultant says the db, which should be SQL Server 2000, was upgraded to 2005. That upgrade, according to them, was the reason for the app implosion. No one can explain how the upgrade occurred.
Can the value of ProviderManifestToken cause an upgrade to the db? For example, if a db is currently 2000 and this app runs with "ProviderManifestToken = 2005", can that force an upgrade on the db? What happens, if anything at all, if the versions do not match?
Do you think that Entity framework contains installation DVD to upgrade your SQL Server 2000 to SQL Server 2005? No it doesn't. Provider manifest token only describes dialect (EF generates queries based on the dialect). It doesn't trigger any changes on the database. Somebody had to upgrade your database (upgrade to a new version is not free - you must have licence for that, it is not something downloaded through windows update).
Btw. SQL Server 2000 is not supported by EFv4 anyway. If you had your dialect set to 2005 and your solution worked with your database then it was 2005 all the time because linq-to-entities queries using First, Single, Take, Skip, etc. generated for 2005 dialect don't work on SQL Server 2000.
I've got experience with MySQL, DB2, and Oracle, but aside from writing a few queries, I've never used SQL Server.
My question is a three parter:
1) For a developer, what are some good "free" client tools to look at, and why (by "free" I mean open source, freeware, or the tools that come with SQL Server itself)?
2) I plan to run Developer or Express Edition on my workstation for development, and either Standard or Enterprise Edition in the testing and production environments. What methods exist if any for transferring data between different servers and the different editions?
3) Are there any common pitfalls that someone like me (who is used to the other database systems that I mentioned) might encountered during development?
TIA
SQL Server Express with tools.
All editions have the same SQL language features and code is 100% portable between them. There are 3rd party tools to synch changes, but moving entire DBs is easy using inbuilt tools.
Nah. The problem with databases is SQL and set theory, not the choice of RDBMS. If you understand databases/SQL you'll be OK.
SQL Server Management Studio which comes with SQL Server (any editions), or you can download it separately. SQL Server Profiler which doesn't come with Express.
Management studio has tools for backup/restore database. You can also consider detach/attach method to synchronize db .
It's hard to say. But if you had Mysql experience you will be pleasantly surprised by SQL Server.
UPDATE
There are so many things that each DB vendor implements differently that it's really hard to focus on some of them. One thing I was not used before is that SQL Server doesn't let unique columns to have more than 1 NULL value(there is a workaround though)
We run SQL Server 2005 exclusively for databases that we use (I'm trying to push to get them upgraded, but alas!). On the client side with Management Studio, are there any benefits to upgrading to SSMS2008 when only connecting to SQL Server 2005 databases? I've seen that Intellisense won't work, so I'm curious if it's worth the hassle.
Yes, there's quite a few improvements intellisense is definitely a big one for developers (Intellisense only works against SQL Server 2008 databases, unfortunately), but there are also other things like T-SQL Debugger, Activity Monitor, the Object Explorer Details
Also, multi-server queries, and the ability to color the connections (get a visual clue whether you're on dev, test or prod system) and a lot more.
See some good background info here at Simple-Talk.
It is up to you. My favorite is search feature. See link for details.
Having worked with SQL 2005 since it came out, upgraded my client tools to 2008 when it came out, and still not upgraded our server, I don't think it is worth upgrading, especially if you aren't moving to SQL 2008 on your server anytime soon. There is no real harm in upgrading, but you need to get familiar with a slightly different tool that IMO is neither worse nor better.
There are a lot of things to like about SQL2008 SSMS, even if you are connecting to SQL 2005 servers:
Customize the columns in the object views, including some very useful ones like DB size
When viewing a query execution plan, it will list any indexes that it recommends
Color-code server connections
Execute SQL statements against multiple servers
In our environment, we have a mix of SQL 2000, 2005, and 2008 servers, so I still use SQL 2005 SSMS to connect to all three (The new "Activity Monitor" in SQL2008 SSMS doesn't work for SQL 2000 servers.)
I don't want to sound like taking sides, but Toad 4.6 rulez! :-)
Exact duplicate:
Advantages of MS SQL Server 2008 over MS SQL Server 2005?
i am a sql developer and i use sql 2005. i want to now to pass to 2008 but i am a little affraid. can anyone gives me some advices about this. should i still continue using sql 2005 or is better pass all my projects to 2008 due to better performace?
Who is going to use your projects; if they are going to customers with existing SQL Licenses then 2005 might be the way to go; assuming they are running 2005. SQL 2005 databases will work on 2008; though if you use some of the new language features in 2008 then the SQL2008 databases wont be backwards compatible to 2005.
If you are controlling where they are going to be deployed; some of the new features in sql 2008 might be of interest; better full text search, improved Analysis services, reporting services and some language tweaks. If you are managing the servers; your admins will likely appreciate the new management features in 2008.
I moved to 2008 because I am heavy into SSIS and have large databases meaning: The backup compression and increased concurrent processes in SSIS for 2008 make it worth it for me.
I moved 6 projects from 2005 to 2008 without any problems except reporting services. To me the biggest benefit is the SQL Management Studio enhancements like auto complete and change history.
The only reason I did upgrade was because I work in education and Microsoft is very gracious on licensing.
In general, unless you hear that it is a disaster, I think you should strive to use the most recent release at the earliest opportunity. The advances in server functionality and the tool set will usually offset the time it takes you to learn the new features. All software is built with planned obsolescence in mind, so you will eventually need to migrate to newer technology. If you make a habit of migrating your systems to the latest technology, you will find that the migrations become relatively painless.
One of the benefits of SQLServer 2008 with respect to SSIS is that it includes very fast bulk connectors for Oracle and Teradata (well, the development and enterprise versions do).
So if you need to move data between SQLServer 2008 and those databases you get this for no additional cost.
See Microsoft Connectors for Oracle and Teradata by Attunity
Another major benefit in SQLServer 2008 is the new Change Data Capture (CDC) functionality which means you can build your application in any way you like and then if at later time you are interested in starting some processing when table X changed, you can turn on CDC for that table and get a change table that contains all the changes to table X with minimal overhead. Ben Hall did a useful post on this.
I think SQL 2008 has somewhat advantage in compare to sql 2005
New data types(date,time,files stream)
2.Backup compressin
3.Data compression
4.policy based management.
If anyone know better answer kindly inform