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
Related
I have an application written in MS ACCESS 2007 using VBA, connecting to an SQL Server at the back end. Both Access and SQL Server are running locally.
My machine runs Access 2010 and MS SQL Server Express 2008 R2 (both 32-bit, on WinXP) with no problem.
I have another machine, Win7 64-bit, running both Access 2010 and SQL Server 2008 (NOT R2) 64-bit.
When I run the Access application on the 64-bit machine, I have a drop down box to select the SQL Server which holds the various databases. When I select the server, after a few seconds I get an error:
Run-time error '-2147024703 (800700c1)':
Automation error %1 is not a valid Win32 application.
When I select the Debug option, the yellow arrow points to:
Set oServer = New SQLDMO.SQLServer
The next line is:
oServer.Connect ServerName, strSQLUser, strSQLPwd
In the watch list, I can see that ServerName, strSQLUser, and strSQLPwd hold the right values to access the SQL Server. I've tested these in sqlcmd and successfully was able to query tables.
Can anyone please help me out on this one? I'm not sure what to do next.
Seems like you've got registered a 32-bit SQLDMO on your system that is being used for connection to the 64-bit instance. Check your registry / file system for SQLDMO.dll versions and register the correct one.
Also check MSDN "Installing SQL-DMO" because SQLDMO was scheduled for remove after SQL Server 2008 R2:
Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
SQL Server Database Management Objects (SQL-DMO) has been removed from SQL Server 2008 R2 Express and the SQL Server 2008 R2 Feature Pack. SQL-DMO also does not support Database Engine features introduced after SQL Server 2000. We recommend that you modify applications that currently use this feature as soon as possible. If you must support SQL-DMO, install the Backward Compatibility Components from the SQL Server 2008 Feature Pack from the Microsoft Download Center. Do not use SQL-DMO in new development work; use SQL Server Management Objects (SMO) instead. You can obtain the SMO documentation by installing SQL Server 2008 R2 Books Online.
Thanks for this.
I looked to find SQLDMO.DLL 64-bit version, but although using the Backwards Comparability package for x64, installing using the MSI did not do the job.
I had to manually extract the files and place the correct version (which is ~2MB larger than the x86 version as an indication to knowing which one is the x64) and then run 'regsvr32 sqldmo.dll ' in the command line (very important: need to run cmd as Administrator for this to succeed).
After the module has been registered, my Access front end run great.
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.
Hi i have a error like " dbFileName cannot be opened because it is version 655. This server supports version 612 and earlier. "
what should i do ? some friend of mine done a project but i guess he done it with sql 2008 and i have sql 2005 is that the reason why i got this error? can i fix it ? if i setup a newer version of sql does it will solve the problem?
www.microsoft.com/express/Database/default.aspx#Installation_Options here sql server 2008 R2 express is available can it be the solution?
thank you...
by the way i found a link of an update http://www.microsoft.com/downloads/details.aspx?FamilyID=E1109AEF-1AA2-408D-AA0F-9DF094F993BF&displaylang=en is this a solution to my problem ?
The VS update in the link is not a solution to your problem. You'll need that update though if you want to use VS to work with a SQL Server 2008 project. And you will have to work with SQL Server 2008 if you want to use your friend's database. To solve your problem you'll need to upgrade to SQL Server 2008. Express edition is fine, as long as the database is less than 4Gb in size. Note that if you continue to work on this database, you won't be bale to deploy your solution to a hosting that is based on SQL 2005, since they won't be able to use your database.
But the real problem you face here is the fact that you treat MDF files as source. You should develop exclusively using T-SQL scripts to deploy your database, and then you won't have any of these problems. You can use a application versioned schema deployment strategy, or you can use a Visual Studio Database Edition project and deploy using vsdbcmd.exe and .dbschema files. Any of this solutions will be way ahead of actually checking in MDF files, exchanging MDFs between team members or copying MDFs at deployment time.
SThe database has been attached to a sql server 2008 instance. You cant attach it back to a sql 2005 server. ee this link for more details:
http://social.msdn.microsoft.com/Forums/en-US/sqlexpress/thread/01ed3b1c-6f29-4518-a3a4-e4e35decc05f
You can download an express version of Sql Server 2008.
You won't be able to open it without installing the same or later version that was used to create the file; you can use the free SQL Server 2008 Express Edition if it the database is not too large.
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.