Is there any chance of installing Reporting Services 2008 against an instance of SQL Server 2000? The docs clearly state that only SQL Server 2005 or 2008 are supported, but I thought I should ask anyway, for ways to bypass this limitation.
I should mention that I am not talking about the data source for my reports (which is a remote data source that can be any type of sql server). I am interested in the databases where the report server stores its things.
No, the reportserver and reportservertempdb REQUIRE 2005 or 2008. You could source data for your reports from a 2000 instance, but your reporting services databases need to be 2005 or 2008.
see: http://msdn.microsoft.com/en-us/library/ms157285.aspx and read the section on Database Server Version Requirements
I have no idea if this would work, however reporting services also depends on the SQL Server Agent service (for subscriptions) as well as the relational databases, so both would need to be compatible. If you have Reporting Services 2008 then you (or your organisation) must own a SQL Server 2008 license of some sort, therefore I cannot see why you would ever want to do this since you can install the SQL 2008 database engine to support your report server (on the same server, otherwise you would need an additional license).
Bear in mind that as of April 2008 SQL Server 2000 is no longer in mainstream support from Microsoft, so you should avoid implementing new infrastructure or functionality using this version wherever possible. The configuration you describe above, even if you got it to work, would be unsupported by Microsoft and probably all ISVs and partners.
Related
I am using a SQL 2008 R2 Express edition. Now that its time to deploy, I need the Standard edition sql server. The database is simple with a million records of addresses which could be queried using google maps with a zip code. Also, it will be storing account information like username and password which are limited(maybe 30-40 accounts). It will be hosted in one server only and once accessible using those account information(not a public web site). I am planning to setup SQL Server authentication. Can any one tell me if 2008 should be enough for my purpose or do I need 2008 R2 for some specific reason? Also 2008 R2 is really expensive compare to 2008. 5 CAL license is enough for me as I will be the only one handling the database. Since, this is my first production deployment, I am not sure what to chose.
Please let me know.
Can I use the new SQL Server Data Tools that come with SQL Server 2012 to create SSIS packages for SQL Server 2008?
I work with both SQL Server 2008 and SQL Server 2012 and I am wondering if I can use SSDT to create and maintain SSIS on both.
No.
See problem with deploying ssis 2010 package
It seems that the backward compatibility offered by SSDT does not apply to SSIS.
Everyone wants a smooth integration process that will allow for proficient system performance. In theory, the SQL Data tools package should work well with server SSIS (SQL Server Integration Services) 2008. Get the intended benefits of both systems when each is installed properly.
In theory, SDT should work with SSIS 2008, as the SQL Data tools is compatible with versions of SSIS dating back to 2005. However, more than a few have complained of getting "not supported" error messages. Some have found that answers lie in their installment procedures, while others have used improper versions of SSIS 2008. Overall, however, the underlying issues lie in the unique qualities of the 2008 system.
One important system aspect to keep in mind is the changes that took place when the 2008 version of the integration system was "rolled out." The new features were to better support the day-to-day activities of administrators than the 2005 and other versions. The advancements in individual components of the 2008 version made it more intuitive but, perhaps, inadvertently more complex to integrate with with other systems. For example, its policy-creation configurations are broken into facets, which are meant to be "matched" to the conditions of your policy. While this offers manual control, it's possible that other systems such as SDT will not integrate with 2008 as easily.
In light of the unique qualities of the 2008 version, as opposed to its predecessors, special attention to specific integration maneuvers is necessary. Also keep in mind that the SSIS 2008 R2 version yields more problems than the standard version.
The changes to SQL 2008 also include some discontinuations. In the move to this particular version, there was a large swath of features that were discontinued. As a result, the version lacks much backward compatibility. These conditions may require significant changes in your other systems.
We have a production database running on SQL 2005. We are using SQL 2008 Management Studio. The issue we are having is that some of the stored procedures/functions we write get code that is compatible with SQL 2008, but not with SQL 2005. The newer management studio doesn't flag this as an error, but when we try to deploy a version, we get a large amount of errors. Is there any way to get 2008 Management Studio to validate code for compatibility?
Thanks!
Even if you are using Management Studio 2008, you dev database should match the prod one. It is an extremely poor idea to develop against a 2008 databse when your prod database is 2005. You can still hook to 2005 databases in management studio 2008. Then you will find out immediately that the code doesn't work. In fact if you are attached to a 2005 database, it will only let you use 2005 syntax. We attached to 2000 database for a long time until we got all the servers upgraded and it wouldn't let us write 2008 specific code as long as the database we attached to was 2000.
If, for some reason (and I stringly recommend against it), you will continue to develop against a 2008 database, I also suggest you look in Book Online for the new features of 2008 and make sure all your devs know which features they should NEVER use. Make sure your code reviewers check code against the list.
You can set the Compatibility Level to SQL Server 2005 (90) under the Options section of the database properties.
Right click the database, select Properties, and then select Options.
I am setting up my development machine and I am wondering if I should install SQL Server 2008 R2 (for Developers) or SQL Server 2008 (for Developers) on my machine.
All of the databases that I work with are on SQL Server 2008 (not the R2). So I am torn. Should install what I am currently using? or should I be a bit forward looking and use the R2 version?
Will the client tools from the R2 install connect ok to the non R2 servers?
I guess in general what I want to know is what are the differences between R2 and non-R2 from a developer's point of view? (I don't really care about back end stuff too much.)
As far as I'm concerned, in R2 more features previously available only in Enterprise edition are now available in Standard edition. Otherwise, no big difference.
For a non-Business Intelligence developer (just plain old OLTP stuff), there's really hardly any difference and any additional features in R2, unfortunately :-(
The only thing that might become interesting at some point is the Master Data Service stuff - can't totally wrap my head around it just yet, so for now : R2 is not a big release for database devs in my opinion. Works great and all - but all the new shinyness is in the BI space.
Well.. in my case I have instaled on my computer SQL server 2008 but I wasn´t able to run SQL server management Studio so I decided to move on SQL server 2008 r2 and it works for me, I was able to start successfully SQL server configuration Studio and to connect to Vs2107 that was my primary goal.
According to this article, Visual Studio 2010 no longer supports SQL Server 2000. However, it's a bit less clear on whether the runtime (and things like ASP.net 4.0, Linq2SQL and EF) will work with it. It seems that only the design-time features require SQL Server 2005 or greater according to that article.
I have a project that requires SQL Server 2000 because it has some legacy SQL Server Extended Procs that don't seem to work in later versions of SQL Server (causes crashes, and I don't have the source to the extended procs). I can do my design work in SQL Server 2005 or 2008 as I don't need the xp's at design time. But I need to know if the final compiled app will function on SQL Server 2000 or not if I use ASP.NET 4.0 and Linq2SQL or EF.
Anyone have any experience getting this to work?
Alternatively, if it did not work, could I get around the problem by using a second install of SQL Server that is SQL Server 2008 and uses linked tables to the SQL 2000?
Yes
Even SQL Server 2008 Native Client supports SQL Server 2000