We have a merge replication that sources on a subscription of a transactional replication. According to this source (Multiple SQL replication types) I need to set the #published_in_tran_pub to true.
So far so good, however now I would like to check if the property is indeed set to true. Does anyone know how to do this?
Microsoft: This merge replication example returns the properties of the published article.
TSQL
DECLARE #publication AS sysname;
SET #publication = N'AdvWorksSalesOrdersMerge';
USE [AdventureWorks2012]
EXEC sp_helpmergearticle
#publication = #publication;
GO
Unfortunately the above query does not return information about the #published_in_tran_pub property.
Thanks in advance
You can query sysmergearticles to check the value of the property #published_in_tran_pub.
Related
We have a transactional replication setup where the subscriber is also a publisher to a second set of subscribers. I think this is because of the slow link between the primary publisher and the subscriber. The subscriber publishes the same set of articles to multiple local subscribers.
One problem we have is when the primary publisher/subscriber setup needs to be reinitialized, we have to remove the second publisher/subscriber setup. We get errors regarding dropping of tables otherwise. They can't be dropped by the initialization process because they are being used for replication by the second setup.
Maybe this is the way it has to be done but I'm wondering if there is a better way. Looking for any tips or suggestions.
Thanks,
Kevin
Maybe. The procedure to add an article (sp_addarticle) takes a parameter #pre_creation_cmd that specifies what to do before creating the article. The default is "drop", but can be "none" (do nothing), "delete" (deletes all data in the destination table), or "truncate" (truncates the destination table). In your case, I'd choose "delete" since you can't truncate a replicated table, either.
But I have to say that if it were me, I wouldn't do that either. I'd make my re-init script a sqlcmd script that looks something like:
:connect $(REPEATER_INSTANCE)
use [$(REPEATER_DB)];
declare arts cursor for
select p.name as pub, a.name as art
from sysarticles as a
join syspublications as p
on a.pubid = p.pubid;
open arts;
declare #p sysname, #a sysname;
while(1=1)
begin
fetch next from arts into #p, #a
if (##fetch_status <> 0)
break;
exec sp_droparticle #publication = #p, #article #a;
end
close arts;
deallocate arts;
:connect $(PUBLISHER)
use [$(PUBLISHER_DB)];
--whatever script you use to create the publication here
Note: that's completely untested (I don't have replication set up at home), but should be pretty close.
Lastly (and rhetorically), why are you re-initializing so often? That should be a rare event. If it's not, you may have a configuration issue (e.g. if you're constantly lagging behind so far that you exceed the distributor retention, increase the distributor retention).
What is the Oracle equivalent of SQL Server's SET NOCOUNT ON?
From the SQL Server documentation:
SET NOCOUNT ON... Stops the message that shows the count of the number of rows affected by a Transact-SQL statement or stored procedure from being returned as part of the result set...
For stored procedures that contain several statements that do not return much actual data, or for procedures that contain Transact-SQL loops, setting SET NOCOUNT to ON can provide a significant performance boost, because network traffic is greatly reduced.
There is no equivalent in Oracle when set nocount on is used inside a stored procedure, simply because it's not necessary to do (inside a procedure or function).
The only vaguely matching thing is set feedback off as mentioned by BigMike
SET FEEDBACK OFF at SQL*plus prompt.
For official docs please refer to this
I have two databases.
Database A - full of data
Database B - backup of database A, but without data
how can I get all data from database A and just merge it into database B?
My thoughts were to just generate an insert of the whole data or something.
Thanks
Take a look at redgate's SQL Data Compare.
OP said:
database is full of triggers and
constraints
Just restore a complete backup of A as a new database and be done with it. Lots of "one off" inserts created by a script will take forever, play havoc with your transaction log, and most likely fail because of FKs, etc.
That would work if you're trying to do something ongoing, but if you want to do it just once and you have SQL Server Management Studio installed, you can have it do the Export/Import for you. Here's a walk-though with some screenshots:
http://www.databasejournal.com/features/mssql/article.php/3580216/SQL-Server-2005-Import--Export-Wizard.htm
If you don't have any identity fields to worry about, and it's a one-time operation, you can do something like this, which uses sp_msforeachtable and dynamic SQL:
DECLARE #SQL varchar(max)
SET #SQL = '
INSERT INTO DatabaseB.? WITH (TABLOCK)
SELECT *
FROM DatabaseA.?'
exec sp_MSforeachtable #SQL
I am creating a stored procedure in Sql Server 2008 database. I want to return the number of rows affected. Which is a better option SET NOCOUNT OFF or RETURN ##ROWCOUNT?
ALTER PROCEDURE [dbo].[MembersActivateAccount]
#MemberId uniqueidentifier
AS
BEGIN
-- Should I use this?
SET NOCOUNT OFF;
UPDATE [dbo].Members SET accountActive = 1 WHERE id = #MemberId;
--Or should I SET NOCOUNT ON and use the following line instead?
--return ##ROWCOUNT;
END
I know that both work, but which is a better choice and why?
After some trying I am coming to a conclusion that SET NOCOUNT is OFF by default inside stored procedures. Is it possible to change this behavior inside my database?
Use ##RowCount. It's explicit and transparent, it is entirely controlled by your code rather than a built-in behaviour.
The NOCOUNT option can be manually set to default to ON (Optons>Query Execution>SQL Server>Advanced). If you set it this way but then declare SET NOCOUNT OFF in your stored procedure then that local setting takes precedence.
Don't use RETURN for values. By convention RETURN from stored procedures is for error codes, 0 meaning no error and non-0 meaning some kind of problem. If you need data back, the appropriate way to do it is with an OUTPUT parameter. It's a little counter-intuitive based on other languages' use of return.
I know that having SET NOCOUNT ON would make a DataAdapter think there was a concurrency conflict.
You can read about it on MSDN. If the code is going to be used by DataAdapters then obviously don't use SET NOCOUNT ON.
It looks like SqlCommand also has this behaviour, which I guess is the reason why the DataAdapter has a problem (as under the hood it will use a Command object).
Reasons for using SET NOCOUNT ON/OFF:
To control the stack overflow while inserting rows into any table.
Passing the T-Sql messages while executing of the queries or nested queries.
To Show or viewing the latest queries executed.
To get information on the latest record escalation.
Why we use SET NOCOUNT on/off ---
Ans : we can understand this by following steps
step 1 : execute query "Select top 10 * from table name".
step 2 : open message window it shows a message "10 rows affected". it creates extra overheads and extends our execution time.
step 3 : to overcome this extra overheads we use SET NOCOUNT ON. If it is On then it will never count the number of row returns instead it sows a message commands completed successfully.
step 4 : By default NOCOUNT is ON then it counts the number of returned rows that is why my suggestion that it should off during creating new procedures to get better performance from database server.
Is it possible to implement something like the following trigger
CREATE TRIGGER [tr_AU_ddl_All_Server] ON DATABASE
WITH EXECUTE AS self
FOR DDL_DATABASE_LEVEL_EVENTS
AS
DECLARE
#data XML
, #rc INT
SET #data = EVENTDATA()
EXEC #rc = __AU.dbo.AU_DDLLog #data
GO
BUT on the whole server. My idea is to capture all schema changes across all the databases in the server.
As far as im concerned this is not possible in SQL Server 2005, but I'd like to know if anyone got something like this to work. I'd like to avoid having to implement a trigger in every single database.
Yes, SQL Server 2005 introducted the "DDL Triggers" - read an excellent article on it here at SQL Team.
This article shows nicely that they are two scopes for DDL triggers - server-wide, or database-wide. Those that are database-wide cannot be applied to the whole server - you'd have to set them up in each database.
Marc