hash join / merge join option

can anyone tell me in what situation you should force a hash join or merge
join option in a query?generally speaking, it's usually a best practice to allow sql server's
optimizer to use whichever type of join it deems to be most efficient
instead of forcing a join.|||I know, but sometimes when I tried to force a merge join, it's actually
faster, although I don't know why.
so can you explain why?
"szeying.tan" <szeying.tan@.gmail.com> wrote in message
news:1109792227.328553.193860@.o13g2000cwo.googlegroups.com...
> generally speaking, it's usually a best practice to allow sql server's
> optimizer to use whichever type of join it deems to be most efficient
> instead of forcing a join.
>|||hash joins usually occur when the optimizer cannot find the appropriate
indexes to use to speed up the query.
therefore, when you force an merge join on the query using a particular
column, it will speed up your query. instead of forcing a join hint,
study your query and determine if you can apply any appropriate
indexes. that way, the optimizer will always use the best possible type
of join.
in general, you want your joins to be loop joins, followed by merge
joins and lastly, hash joins.|||I thought loop join is not good but inner join is faster than loop join in
most of the cases.
I think loop join is better than inner join when you call a query which join
tables from a linkedserver
or when a small table joins a big table.
I agree with you that it's bad pratice to force a merge join or hash join.
but as far as merge join or hash join, in case they can't find right
indexes(it happens pretty often actually), I guess they catergorize the
data into small chunks, so it's easier to match the rows between tables.
"szeying.tan" <szeying.tan@.gmail.com> wrote in message
news:1109793218.822840.168320@.z14g2000cwz.googlegroups.com...
> hash joins usually occur when the optimizer cannot find the appropriate
> indexes to use to speed up the query.
> therefore, when you force an merge join on the query using a particular
> column, it will speed up your query. instead of forcing a join hint,
> study your query and determine if you can apply any appropriate
> indexes. that way, the optimizer will always use the best possible type
> of join.
> in general, you want your joins to be loop joins, followed by merge
> joins and lastly, hash joins.
>|||Loop join and inner join are not mutually exclusive. "Inner" controls the
semantics of how you want rows in the two tables to be related; this is
determined by how you actually write your query. If you don't specify the
semantic type of join, the default is INNER JOIN.
"loop|hash|merge" are the algorithms SQL Server can use internally to
process the join. There is no default.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Britney" <britneychen_2001@.yahoo.com> wrote in message
news:eBzZ4M2HFHA.3484@.TK2MSFTNGP12.phx.gbl...
>I thought loop join is not good but inner join is faster than loop join in
> most of the cases.
> I think loop join is better than inner join when you call a query which
> join
> tables from a linkedserver
> or when a small table joins a big table.
> I agree with you that it's bad pratice to force a merge join or hash join.
> but as far as merge join or hash join, in case they can't find right
> indexes(it happens pretty often actually), I guess they catergorize the
> data into small chunks, so it's easier to match the rows between tables.
>
> "szeying.tan" <szeying.tan@.gmail.com> wrote in message
> news:1109793218.822840.168320@.z14g2000cwz.googlegroups.com...
>|||Britney
I replied to this in the .server group. Please do not post the same question
independently in multiple groups, so that people do not waste time answering
questions that have already been answered.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Britney" <britneychen_2001@.yahoo.com> wrote in message
news:uHk$dz1HFHA.3624@.tk2msftngp13.phx.gbl...
> can anyone tell me in what situation you should force a hash join or merge
> join option in a query?
>|||i think you're confusing the type of join (inner, outer, left, right
etc) syntax and the algorithm that sql server uses under the hood to
process a particular join.
sql server optimizer is very smart (99% of the time ;))
if it can't find the right indexes, more often than not. you're not
designing your indexes correctly. if you want some tips on what indexes
should generally be created per your query's design, please let me
know.|||britney,
generally speaking, merge joins are used if both inputs are sorted on the
join predicate (ie, if there are tables 'orders' and 'order_details', joined
on 'orderid' column, and both tables are indexed on that column). if there
are no such indexes, sql server will choose loop join, or decide to sort
(one or both) inputs on fly and use merge join, whichever method it thinks
would perform better for a given situation. iow, it is not a good idea to
force use of either merge or loop join - unless you 'force' merge join by
adding the appropriate indexes.
hth
dean
"Britney" <britneychen_2001@.yahoo.com> wrote in message
news:eBzZ4M2HFHA.3484@.TK2MSFTNGP12.phx.gbl...
> I thought loop join is not good but inner join is faster than loop join in
> most of the cases.
> I think loop join is better than inner join when you call a query which
join
> tables from a linkedserver
> or when a small table joins a big table.
> I agree with you that it's bad pratice to force a merge join or hash join.
> but as far as merge join or hash join, in case they can't find right
> indexes(it happens pretty often actually), I guess they catergorize the
> data into small chunks, so it's easier to match the rows between tables.
>
> "szeying.tan" <szeying.tan@.gmail.com> wrote in message
> news:1109793218.822840.168320@.z14g2000cwz.googlegroups.com...
>

Hash join

In some cases when I see the query execution plan I found that Hash
join or Merge join or sort operation is taking about 50% of execution
time.Can I do something to improve it? What is the cause of this high
proportion of execution time taken by this operation?
Regards
amish wrote:
> In some cases when I see the query execution plan I found that Hash
> join or Merge join or sort operation is taking about 50% of execution
> time.Can I do something to improve it? What is the cause of this high
> proportion of execution time taken by this operation?
>
> Regards
Merge joins are generally very quick. They are used when you have sorted
intermediate result sets that must be combined. If they are not
presorted, then a sort operation is visible and this will slow down
thing significantly. Imagine combining two sorted result sets. You start
scanning both of them, top down, looking at key values, and creating a
new result set from the simultaneous scan of both. Easy.
A hash join is more involved and is generally used when a result sets
needs to be joined, but there no keys available to relate them. Hash
values are created from the keys and these values are used for scanning.
A more involved process.
To prevent seeing these types of joins (for most queries) make sure your
joins have index support and the join clauses are SARGable.
Where TABLE1.ID = TABLE2.ID -- Needs indexes that contains the ID column
as the first column on both tables
Where LEFT(TABLE1.ID, 2) = LEFT(TABLE2.ID, 2) -- Not SARGable. Index
will not help
Where ISNULL(TABLE1.ID, 0) = TABLE2.ID -- Not SARGable
Post your tables, ddl, indexes, and query for more help.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||I guess the real question is: are you satisfied with the query's
performance?
I mean, what do you care which part of the query execution is
responsible for which estimated portion of the execution? SQL-Server
will try to execute the query as fast as possible, and hash joins and
merge joins are tools that are used in the process.
Gert-Jan
amish wrote:
> In some cases when I see the query execution plan I found that Hash
> join or Merge join or sort operation is taking about 50% of execution
> time.Can I do something to improve it? What is the cause of this high
> proportion of execution time taken by this operation?
> Regards

Hash join

In some cases when I see the query execution plan I found that Hash
join or Merge join or sort operation is taking about 50% of execution
time.Can I do something to improve it? What is the cause of this high
proportion of execution time taken by this operation?
Regardsamish wrote:
> In some cases when I see the query execution plan I found that Hash
> join or Merge join or sort operation is taking about 50% of execution
> time.Can I do something to improve it? What is the cause of this high
> proportion of execution time taken by this operation?
>
> Regards
Merge joins are generally very quick. They are used when you have sorted
intermediate result sets that must be combined. If they are not
presorted, then a sort operation is visible and this will slow down
thing significantly. Imagine combining two sorted result sets. You start
scanning both of them, top down, looking at key values, and creating a
new result set from the simultaneous scan of both. Easy.
A hash join is more involved and is generally used when a result sets
needs to be joined, but there no keys available to relate them. Hash
values are created from the keys and these values are used for scanning.
A more involved process.
To prevent seeing these types of joins (for most queries) make sure your
joins have index support and the join clauses are SARGable.
Where TABLE1.ID = TABLE2.ID -- Needs indexes that contains the ID column
as the first column on both tables
Where LEFT(TABLE1.ID, 2) = LEFT(TABLE2.ID, 2) -- Not SARGable. Index
will not help
Where ISNULL(TABLE1.ID, 0) = TABLE2.ID -- Not SARGable
Post your tables, ddl, indexes, and query for more help.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||I guess the real question is: are you satisfied with the query's
performance?
I mean, what do you care which part of the query execution is
responsible for which estimated portion of the execution? SQL-Server
will try to execute the query as fast as possible, and hash joins and
merge joins are tools that are used in the process.
Gert-Jan
amish wrote:
> In some cases when I see the query execution plan I found that Hash
> join or Merge join or sort operation is taking about 50% of execution
> time.Can I do something to improve it? What is the cause of this high
> proportion of execution time taken by this operation?
> Regardssql

Hash join

In some cases when I see the query execution plan I found that Hash
join or Merge join or sort operation is taking about 50% of execution
time.Can I do something to improve it? What is the cause of this high
proportion of execution time taken by this operation?
Regardsamish wrote:
> In some cases when I see the query execution plan I found that Hash
> join or Merge join or sort operation is taking about 50% of execution
> time.Can I do something to improve it? What is the cause of this high
> proportion of execution time taken by this operation?
>
> Regards
Merge joins are generally very quick. They are used when you have sorted
intermediate result sets that must be combined. If they are not
presorted, then a sort operation is visible and this will slow down
thing significantly. Imagine combining two sorted result sets. You start
scanning both of them, top down, looking at key values, and creating a
new result set from the simultaneous scan of both. Easy.
A hash join is more involved and is generally used when a result sets
needs to be joined, but there no keys available to relate them. Hash
values are created from the keys and these values are used for scanning.
A more involved process.
To prevent seeing these types of joins (for most queries) make sure your
joins have index support and the join clauses are SARGable.
Where TABLE1.ID = TABLE2.ID -- Needs indexes that contains the ID column
as the first column on both tables
Where LEFT(TABLE1.ID, 2) = LEFT(TABLE2.ID, 2) -- Not SARGable. Index
will not help
Where ISNULL(TABLE1.ID, 0) = TABLE2.ID -- Not SARGable
Post your tables, ddl, indexes, and query for more help.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||I guess the real question is: are you satisfied with the query's
performance?
I mean, what do you care which part of the query execution is
responsible for which estimated portion of the execution? SQL-Server
will try to execute the query as fast as possible, and hash joins and
merge joins are tools that are used in the process.
Gert-Jan
amish wrote:
> In some cases when I see the query execution plan I found that Hash
> join or Merge join or sort operation is taking about 50% of execution
> time.Can I do something to improve it? What is the cause of this high
> proportion of execution time taken by this operation?
> Regards

hanging on one table

Hi,
sometimes (often) my merge replication agent hang on this step:
Processing article 'table1'...
or (occasionally):
The merge process is cleaning up meta data in database 'db1'...
table1 is a large table (22 fields, approx 400.000 rows) with no Primary Key.
I don't have any idea with 'meta data' errors.
After this hang/error we always have this happen again the next time we tried again.
what happen with this? pls help...
TIA
echo
can you post the exact error message you are getting?
Also right click on your problem merge agent and select Agent Properties,
click on steps, and then click on run agent. Then click Edit and at the end
of the commands you find there, hit the space bar, and type -QueryTimeOut
600
Then restart your merge agent.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"echo" <echo@.discussions.microsoft.com> wrote in message
news:922613C3-C666-412F-B35B-F70B2B044F95@.microsoft.com...
> Hi,
> sometimes (often) my merge replication agent hang on this step:
> Processing article 'table1'...
> or (occasionally):
> The merge process is cleaning up meta data in database 'db1'...
> table1 is a large table (22 fields, approx 400.000 rows) with no Primary
Key.
> I don't have any idea with 'meta data' errors.
> After this hang/error we always have this happen again the next time we
tried again.
> what happen with this? pls help...
> TIA
> echo

Handling merge replication foreign key conflicts

I have SQL CE clients replicating against a SQL Server 2005 db using merge replication. The DB has a table A and a table B, which has a foreign key to table A. It is common in my application for records in table A to be deleted on the server. I'm running into issues when a table A record has been deleted, but table B records were created on the clients which point to that record. When I sync I get a conflict because the table B records cannot be applied at the server, and the table A delete cannot be applied at the client.

What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.

This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.

Thanks.
Any ideas on this?|||

presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows

- whether DRI or by trigger

if you were using transactional replication the delete child-then-parent would be part of same atomic transaction

- thus maybe you would get both or neither.

possibly using transactional repl with immediate updating would avoid updates to such ghosts.

however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation

seems that you could

1. write custom resolvers, or

2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]

3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]

HTH

Dick

Handling merge replication foreign key conflicts

I have SQL CE clients replicating against a SQL Server 2005 db using merge replication. The DB has a table A and a table B, which has a foreign key to table A. It is common in my application for records in table A to be deleted on the server. I'm running into issues when a table A record has been deleted, but table B records were created on the clients which point to that record. When I sync I get a conflict because the table B records cannot be applied at the server, and the table A delete cannot be applied at the client.

What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.

This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.

Thanks.
Any ideas on this?|||

presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows

- whether DRI or by trigger

if you were using transactional replication the delete child-then-parent would be part of same atomic transaction

- thus maybe you would get both or neither.

possibly using transactional repl with immediate updating would avoid updates to such ghosts.

however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation

seems that you could

1. write custom resolvers, or

2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]

3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]

HTH

Dick

Handling merge replication foreign key conflicts

I have SQL CE clients replicating against a SQL Server 2005 db using merge replication. The DB has a table A and a table B, which has a foreign key to table A. It is common in my application for records in table A to be deleted on the server. I'm running into issues when a table A record has been deleted, but table B records were created on the clients which point to that record. When I sync I get a conflict because the table B records cannot be applied at the server, and the table A delete cannot be applied at the client.

What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.

This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.

Thanks.
Any ideas on this?|||

presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows

- whether DRI or by trigger

if you were using transactional replication the delete child-then-parent would be part of same atomic transaction

- thus maybe you would get both or neither.

possibly using transactional repl with immediate updating would avoid updates to such ghosts.

however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation

seems that you could

1. write custom resolvers, or

2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]

3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]

HTH

Dick

handling different Timezones

I planning on using replication(merge most likely) in an environment where
the subscribers will be in different timezones. Is there way to convert the
datetime fields from the subscriber's to the local database timezone to the
publishers, and vice versa?
Thanks
+---+
William F. Kinsley
Sr. Design Engineer
NextGen Healthcare Info. Sys. Inc
Normally this is done on the application level.
There is no way, other than storing the time as UTC or with time zone
information, that I am aware of doing this.
"William F. Kinsley" <bacardi@.online.nospam> wrote in message
news:%23s5YuzHuEHA.1280@.TK2MSFTNGP10.phx.gbl...
>I planning on using replication(merge most likely) in an environment where
> the subscribers will be in different timezones. Is there way to convert
> the
> datetime fields from the subscriber's to the local database timezone to
> the
> publishers, and vice versa?
> Thanks
> --
> +---+
> William F. Kinsley
> Sr. Design Engineer
> NextGen Healthcare Info. Sys. Inc
>
|||Hi William,
Thanks for your post.
From your descriptions, I understood you would like to know whether there
will be any problems when replicating between different time zones. Have I
understood you? Correct me if I was wrong.
Based on my scope, it won't. We know of many cases where merge is
successfully running across time zones (merge wouldn't be too valuable if
it couldn't ). If you have a look at the usage of getdate in merge's stored
procuedres(identifying those stored procedures would have been useful ),
you will find that merge history tables' use of a datetime (that was
created by getdate) should not be a concern.
Additionally, there is some BOL excerpt for your reference
============
The generation column in these tables acts as a logical clock indicating
when a row was last updated at a given site. Actual datetime values are not
used for marking when changes occur, or deciding conflicts, and there is no
dependence on synchronized clocks between sites. This makes the conflict
detection and resolution algorithms more resilient to time zone differences
and differences between physical clocks on multiple servers. At a given
site, the generation numbers correspond to the order in which changes were
performed by the Merge Agent or by a user at that site.
============
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Thanks for such a detailed reply, this was really not my question, but still
was very helpful. My question is, if I have a user table with a datetime
column, is there a way for the replication process to automatically convert
the datetime from the source databases timezone to the target database's
time zone? I would prefer not to store everything as UTC since I will have
user created reporting on the data.
Thanks
Bill
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:VIGUFEMuEHA.464@.cpmsftngxa10.phx.gbl...
> Hi William,
> Thanks for your post.
> From your descriptions, I understood you would like to know whether there
> will be any problems when replicating between different time zones. Have I
> understood you? Correct me if I was wrong.
> Based on my scope, it won't. We know of many cases where merge is
> successfully running across time zones (merge wouldn't be too valuable if
> it couldn't ). If you have a look at the usage of getdate in merge's
stored
> procuedres(identifying those stored procedures would have been useful ),
> you will find that merge history tables' use of a datetime (that was
> created by getdate) should not be a concern.
> Additionally, there is some BOL excerpt for your reference
> ============
> The generation column in these tables acts as a logical clock indicating
> when a row was last updated at a given site. Actual datetime values are
not
> used for marking when changes occur, or deciding conflicts, and there is
no
> dependence on synchronized clocks between sites. This makes the conflict
> detection and resolution algorithms more resilient to time zone
differences
> and differences between physical clocks on multiple servers. At a given
> site, the generation numbers correspond to the order in which changes were
> performed by the Merge Agent or by a user at that site.
> ============
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
I am sorry for my poor understanding.
If so, I think, as Hilary Cotter had said, there is no such funcationality
provided in SQL Server 2000 and you will have to do it in application
level.
However, it is a great idea to have such expand feature and I'd recommend
that you forward the recommendation to the Microsoft Wish Program:
mswish@.microsoft.com.
Hope the this will be considered in the furture version of SQL Server.
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||I was afraid that was going to be the answer, Thank you for your help
Bill
""Michael Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:qBXAuAmuEHA.2692@.cpmsftngxa10.phx.gbl...
> Hi Bill,
> I am sorry for my poor understanding.
> If so, I think, as Hilary Cotter had said, there is no such funcationality
> provided in SQL Server 2000 and you will have to do it in application
> level.
> However, it is a great idea to have such expand feature and I'd recommend
> that you forward the recommendation to the Microsoft Wish Program:
> mswish@.microsoft.com.
> Hope the this will be considered in the furture version of SQL Server.
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
Welcome!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

Handling autogenerated PK/FK conflicts in merge replication

We use autogenerated primary keys in most of our tables. Some of these keys are also foreign keys in other tables. Right now there is only 1 database sever at a central location. But now there is a need to have multiple database servers at different locations. Data from these remote sites needs to be replicated to the central server. Some data would also distribute from central server to selected remote sites.

If I could resdesign, I would have choosen something like GUIDs for the primary keys or combination of something like ServerName and AutoGenerated number as a combined key. But that's not possible right now. How do I handle merge replication conflicts in this case?

I am looking for some pointers as to how to handle this case. If it were just simple table with 1 primary key, that would be easy as I can throw the primary key on remote server and let the central server create a new key when data is inserted. But in my case, a single table can be related to 5 or more other tables through these autogenerated keys. Any help is much appreciated.

GUID would be easiest however you can also make a composite key with ID and hostname. That way the key will always be unique.

Would not recommend conflict resolver for the primary key, you will end up with a mess eventually i think.

Martin

|||

you can also use identity ranges for subscribers so they don't conflict when they upload back to the publisher server.

Handling autogenerated PK/FK conflicts in merge replication

We use autogenerated primary keys in most of our tables. Some of these keys are also foreign keys in other tables. Right now there is only 1 database sever at a central location. But now there is a need to have multiple database servers at different locations. Data from these remote sites needs to be replicated to the central server. Some data would also distribute from central server to selected remote sites.

If I could resdesign, I would have choosen something like GUIDs for the primary keys or combination of something like ServerName and AutoGenerated number as a combined key. But that's not possible right now. How do I handle merge replication conflicts in this case?

I am looking for some pointers as to how to handle this case. If it were just simple table with 1 primary key, that would be easy as I can throw the primary key on remote server and let the central server create a new key when data is inserted. But in my case, a single table can be related to 5 or more other tables through these autogenerated keys. Any help is much appreciated.

GUID would be easiest however you can also make a composite key with ID and hostname. That way the key will always be unique.

Would not recommend conflict resolver for the primary key, you will end up with a mess eventually i think.

Martin

|||

you can also use identity ranges for subscribers so they don't conflict when they upload back to the publisher server.