January 2008 - Posts
Naming Convention for Table Name and Column Name
By : Kasim Wirama, MCDBA
Naming convention for table and column is necessary to be discussed on this article. You can agree or disagree with what I recommend here, but I have the reason about my recommendation. You need to remember that there is nothing wrong if your naming convention for table name and column name is different with what I discuss here. You need to be consistent with naming standard. I will discuss naming convention for table and then for column
Table
There are 2 kinds of naming convention here :
1. Regular identifier
The criteria for regular identifier are:
a. First letter must be a letter, followed by upper/lower case or underscore.
b. Subsequent characters could be Unicode letters
c. Table name must not list on SQL Server keywords
d. Table name doesn’t contain spaces
2. Delimited identifier
a. Table name is surrounded by square bracket or double quoted
Column
Column naming convention is better with this criteria below :
a. If you use surrogate key, you can add Id as prefix on the surrogate column, for example : table Employee, the surrogate key is EmployeeId column.
b. Other than surrogate key, you give natural name for column.
c. If there are phrases form, separate them with underscore (_) for readability.
Pascal style is more appropriate rather than camel or Hungarian style.
Grouping Sets in SQL Server 2008
By : Kasim Wirama, MCDBA
SQL Server 2008 introduces grouping sets features in query construct. What is grouping sets? To answer this question, there is typical example to illustrate this question. Imagine you are requested to get total sales quantity based on employee and their years, customer and their years and total for each years and total for each years and grant total for sales quantity, you might issue query below :
Select empid, null as custid, year(orderdate) as yearsales, sum(qty) as totalqty from dbo.orders
Group by empid, year(orderdate)
Union all
Select null, custid, year(orderdate) , sum(qty) from dbo.orders
Group by custid, year(orderdate)
Union all
Select null, null, year(orderdate), sum(qty) from dbo.orders
Group by year(orderdate)
Union all
Select null, null, null, sum(qty) from dbo.orders
Notice that you issue 4 select queries to fulfill the request. That’s fine. When you see in the query plan, actually there are 4 times of scanning on dbo.orders table. Another thing that you see on the sample query above is that there 4 aggregations with 3 different groups. It looks like combination among attributes in each groups. Grouping sets makes that query above shorter and more efficient in terms of number of scanning to dbo.orders table, so the query above is written using grouping sets feature in SQL Server 2008 on the following query :
Select empid, custid, year(orderdate) as yearsales, sum(qty) as totalqty from dbo.orders
Group by
Grouping sets
(
(empid,year(orderdate)),
(custid, year(orderdate)),
(year(orderdate)),
()
);
New query construct keyword from the sample query above is Grouping Sets, that’s the new feature of SQL Server 2008. You can specify more than one grouping sets separated by comma.
If you compare second query to first query in terms of execution plan cost, the second query is almost twice more efficient than the first query from my PC. Notice in the execution plan that the number of scanning to dbo.orders in the second query is less than that of number of scanning in the first query.
Datetime2, Date, Time, Datetimeoffset data type in SQL Server 2008
By : Kasim Wirama, MCDBA
SQL Server 2008 introduces date and time related data type, separated from datetime data type that exists in previous version of SQL Server 2008. Let’s examine them one by one.
Date
The range that could be covered for this type is 1 jan 01 to 31 dec 9999. This is the code sample:
Declare @b date;
set @b=’00010101’;
select @b;
Time
The range covered for this type is 24 hours with precision in second is 7 digits millisecond, here is the example :
Declare @b time;
Set @b = getdate();
Select @b;
You can limit precision, for example 3 digit numbers for second fraction, here is the example :
Declare @b time(3);
Set @b = getdate();
Select @b;
For the example, the maximum value for 3 digit fraction of second is 999.
Datetime2
Datetime2 data type is union from time and date data type above. Date range covered is from 01-01-0001 23:59:59.9999999 to 12-31-9999 23:59.59.9999999. here is the example :
Declare @b datetime2;
Set @b=’99991231 23:59.59.9999999’;
Select @b;
You can limit some number below default 7 digits precision of second fraction as below:
Declare @b datetime2(3);
Set @b=’00010101 23:59.59.9999999’;
Select @b;
It looks like there is rounding operation the example above.
Datetimeoffset
This datetime data type is similar to datetime2, but with additional timezone information. Range timezone for this datatype is between -14:00 to +14:00.
Here is the sample code :
Declare @b datetimeoffset;
Set @b=’99991231 23:59:59.9999 +09:00’;
Select @b;
You can specify precision of second fraction.
Declare @b datetimeoffset(3);
Set @b=’99991231 23:59:59.9999 +09:00’;
Select @b;
Interesting result is 1 jan 2009.
"I Don’t Care How You Make BuburAyam”
By : Kasim Wirama, MCDBA
Read this sentence carefully and understand this C# code sample after this paragraph. “I don’t care how you create me, what I want is that I get my bubur ayam. All I need to do is to call chef and I want him to make bubur ayam”
Public class Program
{
Public static void Main()
{
Chef chef = new Chef();
Food food= (Builder)Activator.CreateInstance(Type.GetType(“BuburAyam”));
chef.Order (food);
food.Restofood.ShowItems();
Console.ReadLine();
}
}
Public class Chef
{
Public void Order(Food food)
{
food.Make();
}
}
Public abstract class Food
{
Protected RestaurantFood item;
public abstract void Make();
Public RestaurantFood Restofood
{
Get { return RestaurantFood; }
}
}
Public class BuburAyam : Food
{
Public BuburAyam()
{
item = new RestaurantFood();
item.price = 5000;
item.FoodName = “bubur ayam”;
}
Private List<string> items = new list<string>;
Public override void Make()
{
Items.add(“chicken”);
Items.add(“rice”);
item.FoodElements = items;
}
}
Public class RestaurantFood
{
Public List<string> FoodElements = new List<string>();
Public int Price;
Public string FoodName;
Public void ShowItems ()
{
Foreach(string item in items)
{
Console.WriteLine(item);
}
};
}
Configuring Standard Merge Replication
By : Kasim Wirama, MCDBA
Another sort of merge replication is bidirectional merge replication. Unlike download only merge replication, bidirectional merge replication synchronize data changes between publisher and subscriber. An enhanced feature of bidirectional merge replication is row filtering and table join. On joining related tables, you can specify logical grouping for relationship one to many or one to one and there is no physical relationship between them. For example if there is no physical relationship between orderheader and orderdetail, you can let merge agent know that they are processed as one unit, so it speeds up merge replication performance and you have options to consider the relationship as one unit of transaction.
Besides that you have options that part of filtered data will go on multiple subscriber or only one subscriber.
Open SSMS, expand Replication folder and right click on Local Publications and select New Publication, select database you want to publish in Publication Database section, select Merge Replication and set subscriber type, select tables you want to replicate, and click Articles Properties button, and choose Set Properties of All Table Articles, you see Bidirectional input on Synchronization Direction property and tick item on Resolver tab to enable Subscriber resolve conflict for on demand synchronization. Interesting part comes here on Filter Table Rows, click Add button, click Add filter, select orderheader as table to filter. On 3 section you will see option as I describe on paragraph 2, I choose go only to 1 subscription, click OK, now click Add button again. This time you choose Add Join To Extend Selected Filter. Select order detail, you see that wizard option on number 3 (Specify join conditions) will smart recognize that this is one to many or one to one relationship, and you can also tick Logical Record treat related changes in the filtered and the joined tables as a transaction when synchronizing. Click OK, move to next step of wizard and you configure security for snapshot agent. And rest of the steps is straight forward to follow.
You now successfully create standard merge publication with selected data replicated to one or more subscriber.
Merge Replication in SQL Server 2005
By : Kasim Wirama, MCDBA Other type of replication besides snapshot and transactional replication is merge replication. Merge replication is a type of replication that is similar to transactional replication but it has conflict resolution mechanism that you can configure.Below is merge replication restriction for each version of SQL Servers :1. For SQL Server workgroup edition, merge replication can publish up to 25 subscribers2. For SQL Server enterprise edition and standard edition, there is no limit for maximum subscribers of a publication3. For SQL Server express edition, the edition can only be a subscriber.There are 2 kinds of merge replication, first is when data is only downloaded from publisher to subscriber, changes in subscriber will not be reflected back to publisher, second is when changes in subscriber will be reflected back to publisher.One agent specific to merge replication is merge agent, that has similar function to distributor agent. This article, I would show you how to configure standard download only merge replication, open SSMS (SQL Server Management Studio), expand Replication folder, and right click on Local Publication Folder, choose New Publication on the context menu. On Welcome screen , click Next, choose database that you want to publish in Publication Database step, move to next step.Next step is Publication Type section, choose Merge Publication, and move to next step to specify Subscriber Types. For this demo, I assume all subscribers are SQL Server 2005, move next to Articles section.In Article section, choose table/view/stored procedure/indexed view/function you want to set in your new publication, choose Tables checkbox, and click Articles Properties, select tables you want to make it as download only by checking Highlighted table is download-only option, move to next step.In Articles Issues step, just informational section, move to next step to Filter Table Rows. Because I would like to replicate all data from publisher to subscriber, I just move to next step to Snapshot Agent section, uncheck Schedule the Snapshot Agent to run at the following times, and move to next step to configure Agent Security section.In Agent Security section, specify domain name, and set option to By Impersonating the process account options in Connect to the Publisher section, click OK to return back to Agent Security section, and move to next step, give name for the publication that you go through its creation now and click OK. Subscription creation is similar to any other replication, with additional step on Subscription Type section, when you choose Server or Client resolution regarding to Conflict Resolution. Choose Server resolution if you configure pull subscription, and client resolution if you configure push subscription.
Peer-to-Peer Transactional Replication
By : Kasim Wirama, MCDBA
Another kind of transactional replication is peer-to-peer replication. This is new feature of SQL Server 2005. Concept in peer to peer replication is that 2 SQL Server is in equal positions, each of them will act both publisher and subscriber. No hierarchical position between publisher and subscriber. Distributor of 2 SQL Server should be dedicated for each of them, so you need to configure distributor for each of them.
Peer to peer replication will replicate entire database objects in one database. Replicated database name should be same with its parent, so the mirror database should be at least in named instance of SQL Server. Besides that, row filtering in peer-to-peer replication is not possible and it doesn’t handle data conflict.
For high availability, peer to peer replication solution could be considered, besides other alternatives such as database mirroring, and failover clustering.
Switching Mode between Updateable Transactional Replications
By : Kasim Wirama, MCDBA
In my previous articles, I have discussed about configure standard transactional replication and updatable transactional replication. This article, I would like to share about mode switching that is possible between immediate updating transactional replication and queued updating transactional replication. The scenario that makes this situation happens when connection between subscriber and publishers once breaks down, so you are required to change mode from immediate updating transactional replication to queued updating transactional replication. When the connection between subscriber and publisher gets recovered, you need to change replication mode from queued updating to immediate updating replication.
Location of context switching depends whether the corresponding subscription is push subscription or pull subscription. Let’s see for push subscription and later pull subscription.
Push subscription
After you create updatable transactional replication (queued or immediate updating), create push subscription. To switch between queued and immediate, browse to Local Subscription folder, and right click on the pull subscription and choose Set Update Method.
Pull subscription
Browse to Local Subscription folder, right click on pull subscription and select Properties…, in Subscription Options section, there is Subscriber update method, you can select between Queue changes and Immediately replicate changes.
To easily differentiate between push and pull subscription, I recommend you give push/pull keyword when you give name to your publication for easy maintenance.
Configure Updatable Transactional Replication
By : Kasim Wirama, MCDBA
Transactional replication comes with different kinds of choices depending on your business requirement. If your business requirement needs to replication data to subscriber without having to update back to publisher from subscriber then standard transactional replication is sufficient in this case. But when the business requirement need the changes on subscriber to propagate back to publisher then updating transactional replication will cover for this scenario. Up to now, updating transactional replication is targeted to SQL Server subscriber only. There are 2 kinds of updating transactional replication, i.e : immediate updating transactional replication and queued updating transactional replication. For continuous connection, it is proper to use immediate updating transactional replication. When updating transactional replication is implemented, it requires uniqueidentifier column for tables that will be replicated to subscriber. You couldn’t switch from updating transactional replication to other replication such as standard transactional replication with exception that you switch between immediate updating transactional replication and queued updating transactional replication, so the only possible action for this is to recreate the publication. Additional agent will be created during creation queued updating transactional replication, a queued reader agent. Linked server to publisher will be created for updatable transactional replication. Credential for accessing link server should be in list of Publication Access List of the publication.
This article I would show you how to configure immediate updating transactional replication.
Make sure you turn Distributed Transaction Coordinator for updating transactional replication. Open SSMS, expand Replication folder, right click on Local Publications, and choose New Publications, and you choose tables or other database object in Articles section. Remaining steps is similar when you configure standard transactional replication. If you need more information for the remaining steps, you can refer to my previous article titled Configure Standard Transaction Replication.
Configure Standard Transactional Replication
By : Kasim Wirama, MCDBA
Another replication besides snapshot replication is transactional replication. This replication just moves portion of data through transactional log data from publisher to subscriber, so it is considered much more efficient than snapshot replication. Replication comes into some functionality, i.e., standard transactional replication and subscriber updated replication. For subscriber updated subscriber, there are 2 sorts of the replication, queued updating transactional replication and immediate updating transactional replication. It depends on business scenarios and environment when it is applicable to implement standard transactional replication, queued updating replication or immediate updating replication. When you configure transactional replication, you need to ensure that tables, you want to replicate, have primary key, otherwise transactional replication wizard would not allow you to set up the corresponding publication. This article, I would share how to configure standard transactional replication.
Transactional replication offers you high flexibilities on how you would like to replicate your data to subscriber, it could replication just subset of rows or you can define what DML operation (insert/update/delete) will be executed against subscriber, or manually define insert/update/delete for non-SQL Server subscriber server.
Open SQL Server Management Studio (SSMS), and connect to publisher, expand Replication folder, and right click on Local Publication, and choose New Publication. When wizard comes to Distributor section step, choose local Distributor or remote distributor, and move to next step.
Next step is about configuring snapshot folder. When you configure push subscription, the folder path is about local path because distributor agent resides on distributors; otherwise the path should be in UNC format for pull subscription. UNC format is \\servername\folder name because distributor agent resides on subscriber. After you configure snapshot folder, go to next step.
Next step is about selecting Publication Database, select database whose database object you want to publish, and move next step. In Publication Type steps, choose Transactional Publication and move next step.
In Articles section, select database objects you want to publish and move to next step. In Filter Table Rows section, you can replicates subset of rows from a table to subscribers, by clicking Add button, and you can specify filter criteria after where clause, after configure filter criteria, go back to Filter Table Rows section, and move to next step.
In Snapshot Agent section, you can have options to schedule snapshot generation, and generate initial snapshot. Snapshot Agent will doing work pertaining to snapshot generation. And click Next button.
In Agent Security section, configure access security for Snapshot Agent and Log Reader Agent. After configure agent, move to next step, you are now in Wizard Action sections. Make sure you tick Create the Publication checkbox and move to next step until you give name for the publication and click Finish.
After you create standard transactional publication, you can create the corresponding subscription with similar step as you configure subscription for snapshot replication.
Best Practice Guidance for Data Modelling
By : Kasim Wirama, MCDBA
Good database design should be come from good data modelling. A DBA should have knowledge for data modelling when he designs database. There are some methodologies regarding to data modelling, they are Information Engineering (IE), Chen ERD, generic ERD, and IDEF1X. You can implement generic ERD by using CASE tools such as Microsoft Visio. This article, I would like to give some best practice regarding to design data modelling elements.
Data modelling process have steps from user requirement gathering, from this you sketch to conceptual data modelling, then move to logical data modelling and implement into specific database vendor by creating physical data modelling.
When you are in creating conceptual data modelling, you create entity, its attributes, relationship to other entities, attribute domain, and objects. Here is the best practice for each of items below.
For entities, sometimes a DBA faces sorts of naming convention whether it should be plural or singular form. Actually it’s no problem whether it is plural or singular as long as you are consistent. I prefer to give singular name, because it represents single instance for each row.
For primary/foreign key, it is confusing when you give attributes name same to its entity name. so it’s better if you want to let user be able to identify it by adding some prefix, for example entity name Customer, you give its key attribute as CustomerId.
For relationship name, it is better to give verb-name to explain relationship between 2 entities, but don’t confuse to your user with technical name that describes cardinality and database relationship (one-to-many) because conceptual diagram depicts high level from end-user view, the conceptual data modelling is not intended for developer.
You need to define attribute domain to maintain consistency across database and it can be used as template when you design other databases.
Make sure you define comprehensive objects from user requirement gathering phase to avoid possibility of changing database design in the middle of development phase. It is much better to confirm to your end user with your objects and its interactions to make your database design covers requirements that end-user will expect.
Create Snapshot Publication in SQL Server 2005
By : Kasim Wirama, MCDBA
I have showed you how to set up replication infrastructure by create publisher and distributor in my previous article. By establishing this item, you can create any types of publication (snapshot, transactional, merge and peer-to-peer replication) and define subscription. This article I would configure snapshot publication and its subscription.
Snapshot replication is actually a snapshot publication, this replication is suitable for situation where data changes happen infrequently, data is in small size so the overhead to transfer a lot of data through network could be no problem at all, data is read only and no need to synch back to publisher.
How it works? Based on tables that are needed for snapshot in articles of a publication, snapshot agent transfers data to file into shared folder and writes history into Msrepl_commands table in distribution database. Next the entry and the file is handled by distributor agent to synch to its subscribers that are listed in subscription of the publication.
Here is steps how you create snapshot publication. Open SSMS, right click on Local Publications folder, and choose New Publication, click Next on New Publication Window Wizard window, choose database where tables you want to take the snapshot, choose Snapshot Publication in Publication Type section on next step, choose tables/ view/stored procedure/indexed view/user defined function you want to snapshot and click Next, on Filter Table Rows section you can define horizontal filtering of one table, after you have configure horizontal filtering go to next step.
On Snapshot Agent section, tick Create a Snapshot Immediately……. If you need to schedule the snapshot agent runs on scheduled basis, tick also Schedule the Snapshot Agent… and change the schedule based on your business requirement (for example : generate snapshot once in a year for publishing the data to your branches), and click Next.
On Agent Security section, define domain account security that will be used by Snapshot Agent to access publisher database to snapshot data, it will be put into PAL (Publication Access List), PAL defines list of credentials that are permitted to access publisher database for replication activities, click Security Settings button, choose Run under… and define domain account and its password, and make sure option By impersonating the process account is chosen so that the domain account is used when accessing publisher database. Click OK to return back to replication Wizard window, and at the end of wizard, choose Create the publication check box, and optionally option for Generate a script…, then click Next button, and give name to your publication, and click finish.
Right click on the publication under Local Publications folder, and choose New Subscriptions, it will shows New Subscription wizard, click next, and choose the snapshot publication in Publication section, and choose first option to run distributor agent from distributor (push subscription) at Distribution Agent Location section, then click Next, at Subscriber section, click Add Subscriber button, and after that you can choose existing subscriber database or create new database at subscriber and click Next button, and similar to configure snapshot agent security, you also configure Distribution Agent security on Distribution Agent Security section, and move forward, at Synchronization Schedule section, configure Agent schedule to run continuously, move next, and at Initialize Subscriptions section, tick Initialize column (otherwise replication doesn’t happen), also set to Immediately at Initialize When column. And go to last step to finish the wizard.
You can test the snapshot replication by right clicking on the publication and choose View Snapshot Agent Status, and click Start. And the tables will be get replicated to subscriber.
Configure Publisher and Distributor for Replication in SQL Server 2005
By : Kasim Wirama, MCDBA
In replication architecture, there are publisher, distributor and subscriber. Publisher acts as origins of data, distributor acts as distributes data from publisher to subscriber and subscriber to publisher in immediate/queued updating subscription; and subscriber is destination server that subscribes data indirectly from publisher through distributor. Before you begin to publish your database object to replicate to subscriber, you need to configure publisher and distributor as base replication infrastructure set up. I will tell you how to do this as first step to implement replication.
If you choose to SQL Server Database Services when setting up your SQL Server, Replication component will also get installed. Now you will configure publisher and distributor. Open SSMS (SQL Server Management Studio), go to Replication folder, right click on it, and choose Configure Distribution, Configure Distribution Wizard window pops up and click Next button to move to Distributor configuration from welcome screen. In Distributor screen, you have option to configure distributor in same server with publisher or separate distributor from publisher. If you choose separate distributor from publishers, you need to configure the other server as distributor first before you choose the option. For this demo, I choose distributor server is the same publisher server. It is more scalable to give dedicated box for distributor and publisher.
Click Next button, choose SQL Server Agent to start automatically, click Next button, on next step, you are required to choose whether you put snapshot file into default snapshot folder or your specified snapshot folder. By default snapshot folder is C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData. Ensure folder permission is granted for windows account so that snapshot agent can create file into the folder and distributor agent can read the file from the folder as well. Other thing that you need to know that the path is local path, it couldn’t be applicable when you define your remote distributor or you define pull subscription, UNC naming format is used instead, the format of UNC naming format is \\server name\share folder, for example \\myserver\ReplData. click Next button, you will see entry for specify distribution database and location for distribution database file. Click Next button to move to next section, Publishers section.
In Publishers section, click … button beside first row of Distribution Database column, set Agent Connection Mode property to SQL Server Authentication, and specify username and password that will be used when connecting to publishers from distributor. Click Next button, and you are asked to select configure distribution and generate script file for this wizard. Check both of them, and specify where you want to keep the script and the format (default to Unicode) on next screen, and click Next button, now you have done configure publisher and distributor by clicking Finish button after reviewing the configuration. After the wizard configures distributor and publisher, you can view their properties by right clicking Replication folder.
Replication Agents Role in SQL Server 2005
By : Kasim Wirama, MCDBA
There are some components working together to replicate data from one SQL Server to another. They are called replication agents. In SQL Server, there are 5 replication agents, some reside on distributor, the others reside in subscriber. What kind of role do they have? Let’s take a look.
There are 5 agents involved in replication. They are snapshot agent, log reader agent, queue reader agent, distribution agent and merge agent. Actually behind the scene, they are jobs that run by SQL Server Agent service. So make sure SQL Server Agents get running if you implement replication. Also these agents relate to SQL Server executable, you can find the executable on C:\Program Files\SQL Server\90\COM. You will see Distrib.exe (for distribution agent), logread.exe (for log reader agent), qrdrsvc.exe (for queue reader agent), replmerg.exe (for merge agent), and snapshot.exe (for snapshot agent).
Snapshot agent will take snapshot of schema and data for first time replication, it generates snapshot file and put entry in distribution database relating to the file. Snapshot agent resides in distributor.
Log reader agent will read transaction log of publishers and put the replicated entry into distribution database. It is used for transactional replication. The data will be held in distributor until they are ready to send to subscriber.
Queue reader agent will be used in queue updateable transactional replication. When connection between publisher and subscriber doesn’t continuously connected every time, changes in subscriber will be put in local queue, when there is connection established between them, queue reader agent will take the log from the entry and applies to publishers. The agent resides on distributor. Queue reader agent is used only in queued updating subscription. Another similar this subscription is immediate updating subscription. If you choose one of them, make sure MS DTC service is running on subscriber.
Distributor agent will distribute the replicated data from publisher to subscriber. For push subscription, distributor agent will be in distributor server, and for pull subscription, it is in subscriber server.
Merge agent will work for merge replication, similar to distributor agent; it will apply snapshot and subsequent changes from publisher to subscriber, and perform conflict resolution. The location between push and pull subscription is similar to that of distributor agent.
Difference between Push and Pull Subscription
By : Kasim Wirama, MCDBA
From initiator perspective, replication request could come from publisher or subscriber. Replication request that comes from publishers is known as push subscription and the other one is called pull subscription.
Here is the architecture of push subscription.
Subscriber and subscription are registered in publisher; they are also enabled in publisher. Data snapshot and its subsequent changes are sent from publisher to distributor. Distributor agent will store job history into distribution database and propagate the changes to subscriber. Changes in publisher could be sent to distributor by demand, by schedule or continuously. Replication in push subscription has control in publisher, subscribers do not need to initiate replication request. Distributor agent executes replication scheduling.
And here is the architecture of pull subscription.
Subscriber and subscription are created on subscriber server. Publishers get information about subscriber and subscription and enable them in publisher side. Next distribution agent from subscriber initiates replication request that passes through distributor database to publisher. Publisher receives the request, and looks up information into publication database and give response by sending data (if the data is available), error message (if error message exists) and data history to distribution database in distributor server. Distributor sends data to distributor agent on subscriber. Replication by pull subscription has control at subscriber side instead of publisher, but publication and subscription are still enabled on publisher side instead on subscriber side. If you notice, distribution agent resides on subscriber instead of distributor because subscriber initiates replication request.
Similarity between push and pull subscription are that subscription and publication of them are enabled in publisher side. It means that publisher need to list subscriber. So anonymous subscriber couldn’t request for replication. You can set anonymous subscription only in pull subscription. Subscription and publication with subscriber identification that has access to is known as named subscription.
More Posts