I have been evaluating merge replication, 'push' subscription on SQL Server 2014. If the default resolver is used (I refer to #article_resolver parameter of sp_addmergearticle), all seems to work as expected. However if I use "Microsoft SQL Server Subscriber Always Wins Conflict Resolver" (or any other MS standard resolver for that matter), if the Subscriber is on a different machine, the merge agent invariably gives the following error: "The process could not initialize . Verify that the component is registered correctly."
This does not happen if the Subscriber is on the same machine as the Publisher and Distributor.
The problem seemed to exist in SQL Server 2008 according to some posts but it has been apparently fixed since then. I've tried the following:
#partition_options = 0, as was suggested somewhere.
Copied ssrpub.dll (the resolver dll) to the Subscriber machine (should not really matter as this is 'push' subscription?)
Registered ssrpub.dll with regsvr32 on the Publisher/Distributor machine.
I've also run sp_enumcustomresolvers on the Publisher machine, and it happily showed all standard resolver, including the "Microsoft SQL Server Subscriber Always Wins Conflict Resolver".
Another thought is, I'm using SQL Server Express as the Subscriber (on the remote machine). Perhaps it does not support custom resolvers? (I'm using the full SQL Server in the 'local subscriber' variant, which does work OK as I mentioned before).
Note also that if I create a new publication via SSMS, the Resolver tab of the Article Properties dialog is empty, i.e. it does not list any resolver. The same tab contains the full list of resolvers though, if opened for an existing publication.
Yes it has turned out that SQL Server Express does NOT support custom COM conflict resolvers; it is actually confirmed here: https://support.microsoft.com/en-us/kb/2664701.
There are also custom stored procedure conflict resolvers, but they require a special "Microsoft SQLServer Stored Procedure Resolver", which is a COM resolver, and as such is not supported in SQL Server Express either.
Related
I have a seemingly straight forward project, which unexpectedly faces many obstacles.
I need to move backend data of the existing Access 2016 application from Access to SQL Server 2016.
The challenges I face are:
The simplest and recommended way to migrate Access to SQL Server is using Microsoft SQL Server Assistant (SSMA) for Access. The problem is that my Access is 32-bit Click-to-Run edition. Because the target is SQL Server 2016, I should use SSMA for Access v.7.6.0, which is available only in 64-bit. To use it, I need to install 64-bit Access Runtime, which could not be installed, because per the error message “Windows Installer and Click-to-Run editions of Office programs don't get along”. The earlier version of SSMA for Access 6.0 comes in 32-bit and connects to Access fine, but could not connect to SQL Server 2016, as 2014 is the latest version it supports. Ignoring the warning and forcing the connection to SQL Server 2016 causes error collecting data… Thus, I could not use SSMA.
I was able to migrate the data from Access to SQL Server using SSIS. Now, my challenge is to repoint existing Access tables to their SQL Server copies. I was trying link, but it appears that existing Access tables could be linked only to the file system data source. If I try to make link from the SQL Server side, I could only create new linked tables, which do not do me much good as I am trying to avoid massive changes in the application. Could it be that I am missing something simple here?..
Some Access tables have columns of attachment data type. SSIS doesn’t handle attachment data type correctly. To the best of my knowledge, neither does SSMA. So, when I get to link Access tables to SQL Server, I would probably need to write some code to move attachments from the backup Access database to SQL Server. Is there some other an easier solution?
Any suggestions are greatly appreciated.
That is correct. It is a mess. You can use another (virtual) machine with a clean 64-bit Access install.
Delete the current tables in the frontend and link the SQL Server tables. They may be given a "dbo_" prefix which you can remove by renaming the tables.
This is a rewrite. Attachment fields are not supported in SQL Server. Neither are other fancy features like lookup fields and multivalue fields.
For many years we've had a reporting database that we have written our SSRS reports out of, which includes some linked servers. The linked servers are set up on the SQL instance where reporting services lives, as well as the main databases we use to report out of. We've decide to split off reporting service from the main server, and give it its own house.
I've setup SQL 2014 along with reporting services, and published my reports over there instead. All of the 'non-linked' reports work fine. However all the reports that reference a linked server (that used to work on the main server) now fail with the following error in the log file:
Access to the remote server is denied because the current security context is not trusted.
I thought maybe I needed to set up the linked servers on the new RS SQL server to get this to work. I had assumed that it would pass the entire query (including the linked part) over to the data source specified and my primary server would run it and return the data. Nevertheless, I set up the exact same linked servers on the new reporting services box... but still receive the same error.
All these reports worked just fine on the original server, however they all seem to be having issues on the new server no matter what linked server they are connecting to.
I am at a loss, and would love any ideas you guys may have.
Server A:
Main Data Source. This server contains the majority of our data and also housed our Reporting Services. This server has links to several other SQL servers that I was able to openquery to, and join the data to our main data source. We have many published reports that utilize the linked servers and have historically provided no issues.
Server B:
New SSRS box. This new server was set up in an attempt to off-load all of our reporting needs to another box thereby freeing up any resources required to run reports and SSIS packages. I took all of our existing reports and published them to the new server as-is. Initially I didn't think I would need to recreate the linked servers on this box, since those requests would be going to my main data source (Server A). I've tried both with, and without the linked servers existing on Server B, but get the same results. When the linked servers DID exist on Server B, I was able to query them directly with no errors. The services on Server B are running under the same credentials as those on Server A.
Well, I did some more digging and found my resolution. So the data sources have always been using the end users credentials to run the reports. On the old server, the linked servers use a hard coded SQL account to make the connection. This works fine so long as it is all on one server. However, when running from a secondary server it appears that this scenario will not work. Instead, I found that if I make the data source use the 'same' hard coded SQL account and the linked server to make the connection to Server A, the linked servers work fine.
I have a main SQL Server, running SQLServer 2000, with two (in theory) subscribing servers, each running SQL Server 2005.
One of these is subscribing fine, but the other always seems to fail subscribing, both when attempting to set up the subscription from the publisher (SQL2000) to the subscriber(SQL2005), and when trying to set it up from the subscriber to the publisher, both via Server Management Studio 2008 and via SQL Enterprise Manager
In both cases, the publication is created on the publisher, but a corresponding subscription is not created on the subscriber.
I then get an error message saying "The process could not connect to Subscriber [ServerName]", and no more sign of activity. There's no problem with logins, permissions, etc. The password for sa is the same on both machines, and is different on the 2005 machine that works.
Is this a problem anyone else has encountered?
EDIT: I've now tried adding both a dbSubscriber and a dbPublisher access account on each server so that they're not logging into each other using "sa", but it doesn't seem to have made any difference.
EDIT2: Adding a push subscription does not create a Local Subscription on the subscribing server. Is this normal, or is this the point at which everything is falling to pieces?
Thanks for posting an update, always good to know how things turned out.
There are "complications" and intracacies involved when creating SQL Server Replication topologies incorporating different versions of SQL Server, as it sounds like you are discovering.
Keep in mind that Replication functionality is limited to that of the oldest version of SQL Server in your topology:
Using Multiple Versions of SQL Server in a Replication Topology
We don't really understand what was going wrong, but we think that the 2005 server was unable to accept the 2000 server as a Push Publisher.
We created four different Pull subscriptions on the 2005 server and the first three failed, while the fourth magically worked.
We are accepting this as a blessing from the God of Computers and will not question His benevolence.
I have a server which I need to have as a linked server to another server, using sp_addLinkedServer.
My server's name is in the format "DepartmentName.CompanyName.com", which I can usually change to [blah.blah.com], but which I can't use in the SQL Server Management Studio View creator, because it keeps deleting my square brackets...
On the other hand, because the #srvproduct is SQL Server, I can't specify a name for the server to use, either, so I can't just call it "DepartmentName".
I seem to be in a bit of a catch-22 here. Any suggestions?
The View editor in Management studio (and enterprise manager before it) is, shall we say, rather limited, and prone to exploding the number of references to a table/view if there are complex conditions.
It's much to be preferred that you learn to write CREATE/ALTER VIEW statements in query windows (there are options to script VIEWs to a new query window as ALTER, if you're wanting to update an existing view).
Alternatively, you can add the linked server using, say, the "Microsoft OLE DB Provider for SQL Server", "SQL Native Server", or any of a number of other providers, rather than using the "SQL Server" provider, and then you can specify a different name for the linked server. (We do this in my shop so that our test servers refer to their partners using the same names as are used on our production servers)
E.g.:
EXEC master.dbo.sp_addlinkedserver #server = N'ALIAS', #srvproduct=N'ACTUALSERVER', #provider=N'SQLOLEDB', #datasrc=N'ACTUALSERVER'
I can't see to find a quick explanation of the differences so I can figure out which to use.
One is for a server one is for a Database? Im not sure what that means..
Basically we are doing a new web app and I want to see what these project types can offer me in terms of tracking the DB code/schema etc..
SQL Server 2008 Project: this is used to create a SQL-CLR module, e.g. create a stored proc, a function, an aggregate etc. in C# (or VB.NET), that will be run inside SQL Server.
When you create such a project, and you click "Add New Item" in Solution Explorer, you're given the choice of creating a stored procedure, a trigger, an aggregate, a user-defined function, a user-defined type or a helper class. These will all be compiled into a .NET assembly, which will be deployed to SQL Server and be executed inside SQL Server in the SQL-CLR runtime environment.
SQL Server Database Project: that's only a collection of SQL scripts to be run against a database, to create and manipulate database objects
In a SQL Server Database Project, you basically only get to add SQL scripts - .sql files. Nothing else, really. So it is indeed quite different from the SQL Server 2008 Project type!
The answer here doesn't seem to actually answer the posted question. "SQL Server 2008 Server Project" "SQL Server 2008 Database Project" are both things that exist in Visual Studio 2008 Database Edition, but sadly while there isn't one named "SQL Server 2008 Project" as the answer suggests, there is one "SQL Server Project" that matches the description. Moreover, there isn't a project type anymore called "SQL Server Database Project" (at least not in Visual Studio 2008 Team Suite), although the description given above seems to describe the much older database projects that were at one point available in VS.
After thinking about it further, I'm going to guess that marc_s doesn't have the Database Edition (otherwise known as Data Dude or DBPro) installed. Correct me if I'm wrong.
Sql Server 2008 Database Projects and Sql Server 2008 Server Projects seem to do basically the same thing. I would have hoped that the Server projects would be used for the installation and configuration, and change management of a Sql Server instance, while Database Projects would be used for individual databases inside them...but this doesn't seem to be the case. Has anyone actually been able to determine the differences between them?
After playing around for a bit, the only difference I've been able to find is that Sql Server 2008 Server Projects will always deploy to the master database on the server you deploy to, regardless of what kind of database you import (master or otherwise) when you create the project. So in that case, Database Projects are for your business databases while Server Projects are specifically for the master database on the server that houses your business databases.
Edit: After scouring the VS2008 documentation a little harder, I came across this specification:
"Deploying Server Projects
A database project can contain definitions for database objects, for server objects, or for both. In most environments, developers can change database objects, but only the database administrator can change server objects. You can enforce this restriction by putting server objects in a separate project (known as a server project). You can then restrict version control so that only your administrators can change the server project. In a staging or production environment, the server project and its objects will most often be deployed separately from the project that contains the database objects.
You deploy a server project by using the same procedures that you use to deploy a schema project."
http://msdn.microsoft.com/en-us/library/dd193413.aspx