I'm trying to determine whether DNN 2.0.4 will be compatible with SQL Server 2005 SP4. My company is upgrading their server framework and they're trying to determine (without testing obviously...) if the SQL upgrade will blow up some of their older DNN sites.
I've trolled the boards, liberally dusted with Google magic and even skimmed through the super user manual. The nearest I've been able to get to an answer is that the latest version REQUIRES SQL Server 2005 but there's no indication that it will work with the older DNN.
Anybody out there have any concrete experience I can fall back on?
Because of the large installed base and wide variety of environments, the DNN core team has focused on using very standard SQL and I think if there was any problem, your searching would have turned something up.
Also, I'm not aware of any breaking changes or features in SQL Server 2000 that were removed in SQL Server 2005.
You should be fine. If you do run into a problem it's much more likely to be with a 3rd party module rather than the core. Some 3rd party modules were much quicker to begin to use the new capabilities of SQL Server 2005 and in general are less likely to follow standards or be tested as extensively in a wide variety of environments.
I am running 2.1.2 on SQL Server 2005 without issues. I think that the same would be true of 2.0.4.
Related
I've been testing DataGrip as a SQL IDE recently and I really like it. Particularly I decided to test it because of the multiple database type support.
One issue that I am having, and that is forcing me to keep SSMS open, is the SQL Server Agent. When developing I use it quite a bit to execute jobs from the agent. I cannot seem to get the SQL Server Agent to show up in the DB window in DataGrip (or anywhere else for that matter). Is this even possible? If not then this might be a deal breaker from me when working with SQL Server.
I have tried googling all the possible ways this question could be asked, and I've walked through the 'Connecting to SQL Server' instructions on the JetBrains site for DataGrip.
After doing some research and even reaching out to JetBrains themselves, it appears this is not planned to be supported anytime soon. It's kind of a shame this is the case, but I suppose there's only so much you can do. There is a plugin for this, but it will only work on 2019 versions of DataGrip, not the current 2020 versions. Here is the link for anyone using an older version of DataGrip that wants to incorporate this feature into their IDE.
https://plugins.jetbrains.com/plugin/13473-sql-server-administration-tool
I am currently running SQL Server 2014 and need to install SSAS. Is it best to match the version of SSAS to the version of SQL Server installed or is it recommended that the newest version of SSAS be installed?
I figure the SQL Server environment is set up one of two ways:
1) You should usually match versions of SQL Server and SSAS for compatibility reasons (they were in theory designed for each other).
2) You should usually install the newest version of SSAS because this is the current version that the SQL Server team is focusing their most time on and thus has more bug fixes, security fixes, features, etc. than older versions.
Thanks!
Great question, and in this case the answer is 2:
You should install the newest version of SSAS because this is the current version that the SQL Server team is focusing their most time on and thus has more bug fixes, security fixes, features, etc. than older versions ..unless you have a version installed prior or equal to SQL 2008.
In your case of SQL 2014, install the latest version. There is no need to install the version that was released at the same time as your version of SQL Server.
See The Installing SQL Server Analysis Services Page for more information.
The SSAS and SSMS teams work independantly of each other as is the case with many teams within Microsoft.
In order to offer a recommendation I need to know whether you value stability or features more?
Since SSAS is a separate instance from SQL Server it does not need to be the exact same version as SQL Server. Check out this article from Microsoft on SSAS version compatibility. Based on this article I would recommend you install either SSAS 2014 or SSAS 2016.
At the end of the day, the safest thing to do is install the same version of SSAS. So if you value stability and don't want to deal with unforeseen problems down the road, I would recommend 2014.
If you want a specific feature in 2016, or just like installing the latest and greatest, then you could install 2016.
Note that I have never installed different versions of SSAS and SQL Server.
Just install the latest man, go with the flow, and accept one the answers.
People take time to answer your question.
You can install different versions of SSAS and the SQL Server Data Engine on the same host, yes. Should you? That completely depends on your needs. If it's a requirement that you have SSAS 2016, because it has a feature that 2014 does not, but requirement to use 2014, because 2016 breaks something else, or isn't supported, then you can do that.
There weren't a huge amount of breaking changes in SQL Server 2016 though: Breaking changes in SQL Server 2016; so I'm surprised you want to go to route.
If you have SSAS 2016 and SQL Server Data Engine 2014, that's 2 sets of licences; you'll need one set for 2014 and one for 2016. If, however, you're using just one version (let's say 2016), then that's one set of licences; as your licences gives you access to all the tools that comes with that version of SQL Server (so you also get SSIS, and SSRS). That doesn't seem cost effective.
I realise that this is a question in an answer but I have to ask; Why do you want 2 different versions installed?
We are running SQL Server 2005 and we want to upgrade the instance.
Is it best to go to SQL 2008 or can we jump right to SQL 2012?
What is recommended and what should we look out for?
I am thinking about doing this.
Newest version is often best choice, but that depends on applications, which use SQL server. (Of course hardware and OS should match too.)
If it is your in-house developed app, then you just have to run all tests against newest version, optionally fix problems and let it run.
If it is some 3rd party app, then you need to ask from app vendor, what SQL versions are (best) supported.
If you are developing and selling some application based on SQL server, then you have to support and maintain many versions of server (like we do - we support SQL2000 to SQL2008; SQL2012 is currently in testing phase).
I'm running a classic asp app that's migrating to a .NET 4.0 app; it mostly does CRUD and some reporting (currently not via Reporting Services). I don't do many other kinds of remote jobs - the most I do is a simple replication of one table to another on the same server.
Is it worth going to 2008 given this scenario?
Yes.
Auditing comes with 2008 out of the box.
SQL 2008 provides the ability to limit the resources of queries.
Add CPU's on the fly.
Intellisense. Mentioned already.
Ability to compress data and use less disk space.
Declare and set a variables inline.
Whether it is worth the upgrade dependes on what you value.
I would move to 2008 just to get the new features, bug fixes, and tools.
2008 is easier to develop in (intellisense). It also makes it easier to use things like Reporting Services, Analysis Services, and Integration Services.
2005 is totally fine for the scenario you've got, it's still a premium quality server.
If you're starting fresh and have options - you might also want to consider:
End of Mainstream Support for SQL Server 2005 and End of Service Pack Support for SQL Server 2008 SP1
SQL Server 2005 is officially "end of support" as of April 2011. Personally, I wouldn't pick that version anymore, over 2008 or 2008 R2.
I guess I'm in the minority on this one. IMO, given what little you have told us, the reason for going up to 2008 would be a smooth upgrade path.
If you do not need data compression ( only in the Enterprise version BTW ), or do not need intellisense since you are using something else ( e.g. Visual Studio ) to build your queries or do not need adding CPUs on the fly ( because a quick reboot is acceptable ) then SQL 2008 probably will not provide enough benefit to justify the additional cost (again depending on your licensing situation). At some point, 2005 will become "ancient" technology (probably Nov 2011 when SQL Server 2011 comes out) and that might make things difficult from a feature set/support standpoint for developers. If you can wait until November until Denali is supposed to be released, then I would do that.
SQL Server 2005
is 6 years old
there are 2 later versions
it's going out of support
Go with SQL Server 2008 of course.
Just wondering if it's worth it for a developer to use SQL Server 2005/2008 Developer Edition instead of the bundled SQL Server Express edition that comes with Visual Studio. I'm talking about for initial development of a website, where you need to create SQL scripts to generate the tables and things like that. I know with Express it's easy to add an .mdf file to your project and program against that, but wouldn't it be better to install Developer edition and program against a "real" database that would mimic what you're going to be using in production? That way if you're using VS Professional and can create a "database project" you can include all of your creation scripts and run them in production to recreate the environment.
If you have access to it, you're better off using Developer Edition because it supports more features and larger databases. For example, if you want to restore a 50gb database from your production server onto your workstation to do testing, you'll need Developer Edition.
Another example is if you're working with Enterprise-only features like partitioning, compression or the Resource Governor. Those features aren't available in Express, but they are available in Developer Edition.
If it is good enough for production then how can it be insufficient in development. And SQL Express is quite capable of handling fair loads (the kind of loads that would have stressed serious hardware just a few years ago).
SQL Server Express does not require licensing but has a smaller set of features.
Developing against full SQL Server (and Developer Edition matches Enterprise Edition) always leaves the chance that you rely on some feature that is not in the production edition.
At the very least all your testing (including unit testing) should happen against the edition to be used in production.
In this question, since a "full" version is being targeted for production then developer edition should be a good match, just be careful of enterprise features if you will deploy against Standard.
Personally, I think your development environment should look like as much as you can to your production environment.
SQL Server Express edition
has many limitations like size of database, supports only one processor, etc. It is the "lite" version of SQL Server
SQL Server Developer edition
is basically Enterprise edition but it cannot be used for production.
Be aware that if the success of your backend database relies on the use of enterprise features for development, and you want the same features on production, this will require enterprise license.
It depends on what you are doing. In general, I would say it is fine. If you can get a copy of Developer, I would recommend that route, but a great majority of your work can be done in Express.
Express has basic Reporting, with Advanced Services. If you go beyond the basic Reporting in the product, you will have to move up. YOu also have Service Broker. But, you will not have Analysis Services (no data warehousing) or SSIS (no ETL). If you need either of these features, you have to go to Developer.
You will also not have some of the BI features, as the Express Manager is missing many of the bits in the full SQL Management Studio and BI Developer. If you need these, you will need SQL Server Developer.