Over the weekend my corporate PC got patched (without warning!) and my instance of SQL Server 2008 R2 was removed leaving behind it's MSSQL\DATA folder containing the .mdf and .ldf files.
I am now installing SQL Server 2014 (we still run Win 7 so cannot go to 2016).
Is it possible to import and upgrade all the old databases into SQL Server 2014?
I am aware that I can attach the existing files but that leaves them in the old MSSQL10_50.MSSQLSERVER folder.
Is it simply a case of moving the files to the MSSQL12.MSSQLSERVER folder, attaching, and then changing the Compatibility Level?
Yes, you should be able to just simply attach the existing .mdf files and update the compatibility level and be done with it :-)
Going from an older version of SQL Server (2008 R2 in your case) to a newer one (2014) should never really be a problem (unless you wait too long to upgrade - you cannot go from 2000 to 2014 directly anymore).
The other way around never works - you can never go from a newer version (e.g. your 2014) back to an older one - there's just simply no way to do this (other than scripting our your database structure and contents into SQL files and running those against the other instance)
Related
In testing an upgrade to our Postgres database, we've discovered that one of our oldest versioned migration files is no longer valid SQL. This isn't an issue for the production database which (of course) has those migrations already in the schema_history_table, but standing up any new sandboxes is now made impossible by this broken V file.
What's the best way to bring an old V file into the modern world without forever orphaning our production database?
Of the top of my head I can think of a few possible options.
Configure postgres to enable previous version compatibility. I'm no expert at this, but I think there are some options here.
Just modify the historic migration scripts to they now work with the new version. This will mean that you can't stand up old versions any longer, but does this matter to you? I think that you'll need to run flyway repair after you do this, as Flyway will detect that the files have been tampered with.
Create a parallel set of scripts, one for each version, putting them in different folders. Then use the flyway.locations option to specify different folders depending on the version of the target.
I am trying to debug a program using Entity Framework code first on my personal (work) computer.
We have recently had a domain migration, meaning that the user I log in as now is not the same that I used before. This caused me to loose access to the databases I had on the computer. To get around this, I have uninstalled everything to do with Microsoft SQL Server on the computer, and installed the latest version of Microsoft SQL Server, 2014 - 12.0.4213.0 . I then restored the database I need.
When I first tried to run the program, Visual Studio complained that the project is set up to use SQL Server Express, which was not installed. The recommended solution is to change the project to use SQL Server instead. To do this, I must click on "the database file" and follow the instructions. I have looked through the entire solution. There is a great many files, but I found no good candidate for "the database file."
It seems that my Google fu is not strong enough to find anything about this. So my question is: how do I change the project to use SQL Server?
I also have a second, related question. I tried to solve the problem by installing SQL Server Express. However, when I try to restore the database to this, no base appears in the drop down list. When I try to run the program now, I get another error:
Unable to create the file 'c:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS\MSSQL\DATA\Timelønsblanket.mdf' because it already exists.
I guess that this is also why I cannot restore the database. What I have found in websearches warns that I should not manually delete .mdf files.
Any advice on what to do?
I have solved the problem. All that was needed was a correct connection string. No need to find a "database file".
We are in process of upgrading Sitecore 6.6 to 7.2. Part of upgrade is to migrate all the media items from 6.6 to 7.2.
I tried creating a package but the package size is too large and times out on package installation.
I found link below using Powershell Console where it shows copy-item command:
http://blog.najmanowicz.com/2011/11/18/sample-scripts-for-sitecore-powershell-console
I attached the 6.6 to 7.2 version where I can access the 6.6 DB. However copy-item doesn't seem to support different databases.
Could someone please help how I can use SiteCore Powershell or similar to migrate media items from 6.6 to 7.2?
I had a similar issue with a (very large) media library with a similar migration. Packages seems to bomb out around the 2GB mark, instead serialize the items:
Delete everything from /Data/Serialization
Open the media library. Makes sure you have the Developer tab
showing (right click somewhere on the toolbar and enable it
otherwise)
Select your root media item then Serialize Tree
Wait...
Copy the serialized files from /Data/Serialization to your new
server
From the toolbar select Update or Revert Tree depending on your requirements
Profit.
You can find more info in the Sitecore Serialization Guide and this post by Brian Pedersen
You should be able to do this in Powershell too (from my understanding). You need to:
Add the database to your connectionString.config
Add that database to your web.config to <sitecore><databases><database>. You can copy the existing master node and rename the id attribute to match your conneciton name
Your legacy database should now be connected to Sitecore interface, you can check it is present in the database selector list from the right of the desktop
The powershell command now needs a "from" and "to" location. Assume your database is called "legacy_master", the following should work:
copy-item "master:\media library\*" "legacy_master:\media library\"
I've found Hedgehog TDS (and sometimes Razl) quite useful for doing this.
Create a new TDS project (don't version control it), and download all the items you need to your local machine. You can for example connect the "Debug" build to your source 6.6 instance, and a "Release" build to your target 7.2 instance. Then you can just synchronize the items to your target machine. It's sometimes good to synchronize one or a few branches at a time if you have long latency connections.
The good thing about this is that you're in total control of your content and can see what fields are updated etc. During an update process, it's sometimes useful to compare other parts of the db as well, just to ensure you don't miss any changes you've made to the platform.
Since I mentioned Razl as well: I've found Razl quite good if you have a whole branch that you know should be transferred from one db to another (such as the case you describe). TDS is a bit slower, but more universal - and you may have a TDS license already so it may not be worth an additional Razl license.
I've just added item transfer from one DB to another so you can Copy-item between databases starting with Sitecore PowerShell Extensions 3.0. Thanks for the great idea!
Just to add another option you can perform tasks like this using Revolver.
WARNING: Try this in a test environment first
if we assume that:
the context item is the media library item
the current database is master
the target database is called master72
then something like this should work:
cp -r -n master72/sitecore/
I have some issue I can't find any info about!
I did a clean install, and VS2010 was not yet installed when it occured!
My colleagues don't seem to have this issue while having exactly the same software!
Sql Server 2008 R2 is fully up to date with SP1 etc.
The issue:
My intellisense works!
For example when I type SELECT * FROM --> right after the last space I see my schema or database or table names!
What doesn't work is:
When I continue SELECT * FROM ma" --> now the database "master" is selected! Normally when I type "." (a dot) I would get SELECT * FROM master., but I just get SELECT * FROM ma.
This is SOOO annoying!!
I have fixed this in the past by installing a Management Studio from the NON R2 version, but I just have a fresh install and I would like to know how to fix this, or at least know the cause?
I hope I described my issue properly!
Kind regards,
Wim
This behavior was changed at some point. I have to type Enter and then the dot in SQL Server 2008 R2.
In SQL Server 2012, when you see the auto-complete list, you need another keystroke to actually select it (e.g. down-arrow), then the dot works. You may want to download SQL Server 2012 RC0 and see if the updated IntelliSense functionality is slightly better (though, admittedly, not perfect and still not how it used to work).
In case you're worried that SSMS 2012 is not worth your time yet, please see this question over on ASK SSC: http://ask.sqlservercentral.com/questions/86305/sql-server-2012-ready-to-use.html
Environment: Visual Studio 2005, SSRS 2005 with Sharepoint 2007 integration
Have a project with two reports and one data source. Has already been deployed to production sharepoint farm.
Needs an enhancement. Change properties to point to test farm and try to deploy:
"Access to the path 'c:\documents and settings\\my documents....\RegLog.rds' is denied"
Path is correct, and properties of files are read-only (because the files are checked in to source control). Now, I understand that SSIS packages won't execute if they are read-only (which is stupid) but I am fairly certain I have deployed SSRS reports and data sources before without having to check them out first. On the other hand, I do know that deployment requires the file to be modified in some way. But the modified version will be in Sharepoint, not in visual studio, and its extension will be .rsds, not .rds (which is the VS name)
I also think it is unusual that the path has been lower-cased. Shouldn't matter in Windows, but it's the first time I have ever seen "documents and settings\\my documents" not all initial caps. So maybe it matters. But this project deployed before without problem.
I was having this problem as well. To fix it, I did a build of the report project (which before converting from 2005 to 2008 I'd never had to do before). Once I did that, it worked just fine.