Basically we have a number of branch office's that will be running the application using a local data source. It is important that this data source be local as we cannot afford the possibility of downtime due to internet connectivity as well as possible latency issues etc.

The idea was to design the data so that it would replicate to a centralized DB as well as replicate back to the individual offices using a PK guid field and having an officeid field to indicate the office that generated the data.

So branch A would replicate to main server and then back to branch B and vice versa thus all branches would have a "full" set of data that would then be filtered by the officeid field in the data so they would only be "looking" at their data. 

The problem was with trying to update a record with the guid PK. It would throw an exception and bomb out. I remember talking with Ben about this and do not remember what the outcome was. Due to another project I had to put this on hold and am just starting to get back into thinking about design issues.  I was wondering if this has been resolved since then or if you guys have any other suggestions on how to handle this type of scenario.

Thanks

PAul 

CREATE PROCEDURE MyTableInsert
   @pk UniqueIdentifier OUTPUT,
   @field1 VarChar(50)
AS
   SELECT @pk = NEWID()
   INSERT INTO MyTable (pk, field1) VALUES (@pk, @field1)

You have to manually assign the GUID since if you just put NEWID() in as the default value of the column, there's no way to get it back out.

As for the ROWGUID field that is used for replication, if it is also the primary key, then you're done, but if it's a separate column, then you'll want to set the field in the SetDefaultValues() event handler to DbNull.Value so that the server can assign it; you won't have to worry about retrieving since it's only used for replication.

Paul