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.
Related
I have database created on SQL SERVER 2008. I want to upgrade it to SQL SERVER 2016. what is the best way to upgrade the whole database?
Thanks in advance.
Migration can be done many ways from 2008 to 2016. In-house upgrade, backup restore, etc. Different approaches are explained here:
https://learn.microsoft.com/en-us/sql/database-engine/install-windows/upgrade-database-engine
But simple backup/restore approach is the always better in my practical understanding. Also It has links for SSIS/SSAS/SSRS if required plan for those. Each has different approaches...
Major things to consider are how to remove deprecated features and how to make use of new features:
Deprecated features:
2012:
https://technet.microsoft.com/en-us/library/ms143729(v=sql.110).aspx
2014:
https://msdn.microsoft.com/en-us/library/ms144262(v=sql.120)
2016:
https://learn.microsoft.com/en-us/sql/database-engine/discontinued-database-engine-functionality-in-sql-server-2016
You can use new AMR tool to identify what tables you can use for in-memory also you can do analysis of columnstore indexes etc using below:
https://blogs.technet.microsoft.com/dataplatforminsider/2013/09/17/new-amr-tool-simplifying-the-migration-to-in-memory-oltp/
I had big problems upgrading from 2008 to 20014 as it complained about 2008 SP2 missing, but there where additional messages about missing instance ID's or nothing needed to be installed.
The upgrade from 2008 to 2012 was a better move as the 2012 is probaly better designed to deal with a previous release.
Once 2012 was installed I moved to 2014 with no problem and did not have to care about attached databases. It just upgraded.
I had to use the "SQL Server Configuration Manager" to enable Named Pipes or TCP/IP connection in the "SQL Server Network Configuration" section, and enable the new SQL service .exe in the windows firewall.
To add it to the firewall the service exe "sqlsrvr.exe" was identified using the Windows task manager and using "properties" optaning the path to the .exe.
The installation makes you nervous but once installed you know SQL Server is one of the few Microsft products that does not bother you. It just works.
Instead of downloading missing servicepacks manually it was easier to run Windows update and have it suggest SQL server sevicepacks. Winows update actually helped before migrating to the next version.
Here is a nice chart of sql server editions with links to downloads:
Microsoft SQL Server Version List
version of my database is 661.
when i attach my database in new version of sqlserver, version of my database changed to 665
Automatically.
I don't want to change version of my database.
how can i do that?
You can't prevent automatically database version upgrade when you're attaching/restoring database from lower to higher version of SQL Server.
Source: A lot of years of experience.
BUT, you can do a manual migration of higher version database into lower version by doing THIS
Well, I think you are using SQL Server 2008 R2 database which are 661 version. Hopefully you are trying to attach 2008 R2 to an SQL server 2008 instance but once the database has been upgraded to an 2008(665 version), it cannot be downgraded to SQL Server 2008 R2(661).
You need to uninstall SQL Express and reinstall the latest version to fix the problem.
You can't stop it changing the version, when an older version database is attached to a newer version of SQL server, it must perform these upgrade steps so before the database can be brought online on the new version. These upgrades are internal to SQL server and include things like file format changes etc, they themselves should not affect behaviour of your user code (although the changes in the new version of the SQL engine might).
The only significant result of these upgrade steps is that the database can no longer be attached or restored to an older version of SQL server.
Has anyone here moved the database underlying a SP 2010 install from one database instance to another (same data, just hosted in another instance)?
For example. we just want to move the database to a diffrerent machine.
In addition, has anyone moved SP 2010 from using SQL Express to a higher version of SQL Server? I would like to run some proof of concept tests with SQL Express, and if all goes well, then move to SQL Standard or Enterprise.
Cheers,
Daniel
Check out the following article:
http://technet.microsoft.com/en-us/library/cc512725.aspx
I don't think you'll run into any problems, just make sure you aren't going backwards in versions between databases. Backing up a database in SQL Server 2008 and restoring in 2005 isn't easy.
I've never done this with SharePoint, but I believe it lets you specify the location of the configuration database. Then you just need to match the user permissions.
The TechNet article "Move All Databases (SharePoint 2010)" is your main guide.
Note that this article contains the following warning:
The new database server must be running the same version of Windows
Server and Microsoft SQL Server as the existing database server.
This in NOT true!
Both from my own experience in migrating SharePoint databases and talks I've had with Microsoft Primary Field Engineering, I can say this method also works when SQL Server versions differ. But only if you upgrade to higher SQL Server versions (i.e. SQL Server 2005 to SQL Server 2008 R2). I was told this scenario is also fully supported by Microsoft.
Also, don't forget to update the database compatibility level for the migrated databases. This should future-proof your databases and enable advanced SQL Server optimization.
I am using SQL Server 2008 express edition but I want to make my databases still in 2005. How can I set it up to only show features that a 2005 database can use?
Like for instance I don't remember there being a "date" type. I only remember "dateTime".
I don't want to be using features that 2005 can't support and I later on upload my db to the my hosting site that uses 2005 still and find out I am using things not supported by it.
You won't be able to upload the database, just a script of it. Even when in 90 compatibility mode, the physical structure of the database will be the 2008 one and the hosting site won't be able to load it.
Note that the compatibility level does not necessarily mean that the new features of SQL 2008 are not available, but instead it simply means that (some) features that existed in 2005 will work the same way in 2008. The complete list of compatibility mode changes is on MSDN. In particular there is nothing to prevent the usage of a datetime2, date, time or any new time in a database set at compatibility level 90. In fact such would be impossible simply because the the compatibility level can be changed after a table is created.
You are going to either develop against a SQL 2k5 instance, or read the product manual and learn what features are available in what version.
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.