I have two SQL Server 2008 instances, one running Workgroup Edition (publisher) and the other Standard (subscriber)
I am trying to replicate a database but I am getting errors when it tries to create the database at the subscriber because it thinks it is running SQL Server 2005 for some reason.
Has anyone had this issue before?
I am getting this error
Column Location in object Members contains type Geography, which
is not supported in the target server version, SQL Server 2005.
Have you checked compatibility mode for the databases?
For example:
SELECT compatibility_level
FROM sys.databases WHERE name = 'YourDBName';
Related
How open my SQLServer2008R2 database in SQLServer2012. When I open the database these problems happened:
I can't edit and open tables because this error show:
Invalid prefix and suffix characters.
When I want design tables this error show:
The backend version isn't supported to design database diagram or tables.
When you detach and attach database, the compatibility level of old database is maintained. It is one of the limitations of detach and attach method.
Reference
If we attach a database having a higher version, SQL Server maintains
the database compatibility. We can change the compatibility level once
the database is online
Once you change the compatibility level to suit SQL Server 2012, you can use the new features of the SQL Server 2012.
Read more on upgrading database
ALTER DATABASE DatabaseName SET COMPATIBILITY_LEVEL = 110
GO
I was wondering if there are any problems with having a SQL Server 2012 replication publisher together with some SQL Server 2005 replication subscribers?
Does anybody have some documentation from Microsoft regarding this?
I'm asking because a colleague of mine keeps telling us that it will not work.
Does it also go the other way around? (2012 = Subscriber & 2005 = Publisher)
Thanks
Zarkos
Depends on the type of replication that you're using...
From MSDN:
A Subscriber to a transactional publication can be any version within two versions of the Publisher version. For example: a SQL
Server 2005 Publisher running can have SQL Server 2012 Subscribers;
and a SQL Server 2012 Publisher can have SQL Server 2005
Subscribers.
A Subscriber to a merge publication can be any version less than or equal to the Publisher version.
I thought that SQL Azure was built on top of SQL Server 2012, but the compatibility level when you create a new database is 100 (SQL Server 2008's compatibility level), not 110.
SELECT compatibility_level FROM sys.databases WHERE name = 'Test';
I tried changing it to 110 using the two methods that I am aware of:
ALTER DATABASE Test SET COMPATIBILITY_LEVEL = 110;
--> Incorrect syntax near 'SET'.
EXEC sp_dbcmptlevel 'Test', 110;
--> Could not find stored procedure 'sp_dbcmptlevel'.
The reason this is an issue for me is because SQL 2008 doesn't support geography shapes which cross hemispheres, so if you zoom out a map to see the world and try to store the bounds of the map it will fail. Pretty silly right?
I thought that this would not be an issue in SQL Azure, because it has been fixed in SQL Server 2012, but when I try to create a shape that crosses hemispheres I get the following error:
Microsoft.SqlServer.Types.GLArgumentException: 24205: The specified input does not represent a valid geography instance because it exceeds a single hemisphere. Each geography instance must fit inside a single hemisphere. A common reason for this error is that a polygon has the wrong ring orientation. To create a larger than hemisphere geography instance, upgrade the version of SQL Server and change the database compatibility level to at least 110.
So it is telling me to change the compatibility level, like it knows that this has been fixed already, but I can't figure out how to do that in SQL Azure. Anyone have a suggestion of something to try? Or let me know if it just is not possible right now?
It is hard to say if the current SQL Azure is based on SQL Server 2008 or 2012 however November 2011 update adds lots of new feature to it from SQL Server 2008 and 2012. More Info on Database Engine Versions:
Updated Engine Version: This release updates the underlying SQL Azure database engine version from 11.0.1477.26 to 11.0.1750.34 as it is rolled out across data centers.
The following link talks about what is and what not supported with SQL Azure comparative to SQL Server 2008 and SQL Server 2008 R2:
http://msdn.microsoft.com/en-us/library/windowsazure/ff394115
The following links adds more info about what new Programmability Enhancements are added in SQL Azure from SQL Server 2012:
http://msdn.microsoft.com/en-us/library/windowsazure/hh987034.aspx
UPDATE: August 2015
Azure Sql Database V12 has a default compatibility level of 120 with possibility to go up to 130 or down using ALTER DATABASE SET COMPATIBILITY_LEVEL syntax.
Using a VS2010 SP1 Data-tier application project, I created the simplest database I could:
CREATE TABLE [dbo].[Table1]
(
column_1 int NOT NULL,
column_2 int NULL
)
I then successfully built the .dacpac, and verified it by deploying it using SSMS 2008 R2 to a local SQL Express instance (everything worked fine).
I then tried using SSMS 2008 R2 to deploy the .dacpac to a SQL Azure server. The wizard managed to get through every step (including creating the database and creating the schema), but failed on the last step - "Registering the DAC in DAC metadata" - with an IndexOutOfRangeException (see below).
I tried to do this against an existing SQL Azure server, against a new SQL Azure server (both fail with the same exception), and against a SQL Azure server with an empty database by the same name (this one failed with an SSMS runtime exception).
I'm now out of ideas. Any ideas on how to deploy .dacpacs to SQL Azure would be greatly appreciated.
System.IndexOutOfRangeException: Index was outside the bounds of the
array. at
Microsoft.SqlServer.Management.Smo.SqlPropertyMetadataProvider.PropertyNameToIDLookupWithException(String
propertyName, PropertyAccessPurpose pap) at
Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetDbComparer(Boolean
inServer) at
Microsoft.SqlServer.Management.Smo.SqlSmoObject.InitializeStringComparer()
at
Microsoft.SqlServer.Management.Smo.AbstractCollectionBase.get_StringComparer()
at
Microsoft.SqlServer.Management.Smo.SimpleObjectCollectionBase.InitInnerCollection()
at
Microsoft.SqlServer.Management.Smo.SmoCollectionBase.get_InternalStorage()
at
Microsoft.SqlServer.Management.Smo.SmoCollectionBase.GetObjectByKey(ObjectKeyBase
key) at
Microsoft.SqlServer.Management.Smo.DatabaseCollection.get_Item(String
name) at Microsoft.SqlServer.Management.Dac.RegisterDacStep.Execute()
at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.ManagedActionStep.TransactionalStep.DoExecute()
at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.ManagedActionStep.Execute()
at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.ExecuteActionSteps(IEnumerable`1
managedActionSteps) at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.Go() at
Microsoft.SqlServer.Management.Dac.DacStore.Install(DacType dacType,
DatabaseDeploymentProperties deploymentProperties, Boolean
skipPolicyValidation, Boolean skipDacRegistration)
Do you have the latest build of SSMS? You should be running SSMS R2 SP1. It has fixes for the DAC PAC specifically.
Here it is: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26727
According to Microsoft, there is apparently some kind of issue around which order you install VS 2010 SP1 and SQL 2008 R2 SP1.
Herve's answer may address the problem as well (i.e. reinstall SQL 2008 R2 SP1), but I was not able to verify it because I already solved the issue by following the SQL Azure team's recommended solution - go to http://www.microsoft.com/download/en/details.aspx?id=26728 and download / install the new SMO MSI (which is listed as 1033\x64\SharedManagementObjects.msi).
Thanks MS!
I have a Windows 2008 Server (x64) running Microsoft SQL 2008 (x64) and I'm creating a Linked Server connection to an Oracle server. I'm able to make the connection, but I cannot see any information regarding which schema a table belongs to.
In SQL 2005, my linked servers show the schema information as I would expect.
Does anyone know how to resolve this issue? Is it an issue with the provider, OraOLEDB.Oracle?
Any help or pointers would be appreciated.
#Boojiboy - When you are looking at the tables via a linked server, there used to be a column for what schema. It appears that in the latest the new Oracle OLEDB drivers don't show this information any longer.
It looks like sp_tables_ex will do the trick, it came from the below article.
--verify tables OK exec sp_tables_ex #table_server = 'LINKED_ORA',
#table_schema='MySchema'
#table_schema is optional. If not
provided, you will get a list of all
tables in all schemas.
http://it.toolbox.com/blogs/daniel-at-work/linking-sql-server-2005-to-oracle-26791
Also in the SQL 08 > Server Objects > Providers
make sure your OraOLEDB.Oracle provider is allowing inprocessing