Merge rplication - records not being replicated.

We are replicating 5 subscriptions to 500 users with MSDE databases. All
databases are SQL Server 2000 SP4.
The issue we are seeing is that some users are not seeing all the records
they should. (Merge replication) Examples:
User A creates some new records. The records get replicated to the server
and then are not in user A's database (they should still be in the users
database). There are no conflicts. Re-building the snap shot and
re-initializing with the upload changes selected does not fix the issue.
Re-building the snap shot and re-initializing with the upload changes Not
selected does fix the issue.
Any suggestions for tracking this proble down would be appreciated.
Are you using any dynamic filters? If the added rows on A are not allowed
according to the filter, the row is outside of the partition and this could
account for such behaviour.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
We are using dynamic filters. The users are only allowed to add records
that are in the partition.
|||Then this is normal behaviour.
It would help if you explain a little more about what you would like to
happen.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Merge reversed

Running Win 2000 & SQL 2000
I have a merge publication/subscription (rows are
filtered by location), replicating data between 16
servers (15 remote location & a main office). When data
is changed at the a remote location, the changes gets
propagated to the main office, but at some point, the
change gets reversed.
Any idea what is causing this?
Larry,
when you say it gets reversed, do you mena the row is deleted from the
subscriber? This could be caused if you are partitioning data and a row has
been added on a subscriber which doesn't accord with its filter.
HTH,
Paul Ibison
|||Look in the conflict table, for the article, on the publisher. This might
give you a clue as to what is going on.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||Paul,
No the row is not deleted, but changed back to its
original state, prior to being updated at the
subscriber. This happens sporadically, but is causing
MAJOR problems.
Larry...
|||Rand,
There is nothing in the conflict tables for any article
in the publication.
Larry...
|||I saw your reply to Rand and if both filtering and conflicts are ruled out
(and no user on the publisher is altering the data!) then this is very
strange. I'd use profiler or an audit trigger to capture what is going on.
HTH,
Paul Ibison
|||Thanks Paul...will do.
|||Does the MSmerge_history table on the distributor offer any reason why
the updates were not applied?
Reinout Hillmann
SQL Server Product Unit
This posting is provided "AS IS" with no warranties, and confers no rights.
anonymous@.discussions.microsoft.com wrote:
> Rand,
> There is nothing in the conflict tables for any article
> in the publication.
> Larry...
>

Merge Replication: Insert Trigger ONLY when replicating

Hello,
I have a scenario where clients enter data into a MSDE local database on
their laptop. I would like to add a trigger on that table that fires only
on the Server (SQL2K Ent.) when they are synchronizing when a new records
has been inserted. By looking at the Merge trigger automaticcaly generated
on the table, I found something interesting:
"if sessionproperty('replication_agent') = 1 and (select
trigger_nestlevel()) = 1"
Therfore, I've created my trigger like the following:
Create Trigger tg_Inserted On tblBlaBla FOR INSERT
AS
if not sessionproperty('replication_agent') = 1
return
Insert Into tblTest (Account_Code, Product_Code, DateCreation)
Select ins.Account_code, ins.Product_Code, GetDate()
From Inserted As Ins
I've done some test and everything works fine. However, before putting this
in Production, I was wondering if I absolutely need to put the "Select
trigger_nestlevel() ..." or not. I've read in the newsgroups and some are
saying you need to, some are saying you don't need to... Since it is a very
well documented feature, can anyone confirm me the proper way of doing this?
That would be greatly appreciated. Thanks.
Nest level check allows to avoid ping-pong traffic from subscriber to
publisher and vice versa
But in your case that should matter only if you are also replicating table
tblTest
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"Christian Hamel" <chamel@.NOSPAM.com> wrote in message
news:udebeQ7WFHA.2692@.TK2MSFTNGP15.phx.gbl...
Hello,
I have a scenario where clients enter data into a MSDE local database on
their laptop. I would like to add a trigger on that table that fires only
on the Server (SQL2K Ent.) when they are synchronizing when a new records
has been inserted. By looking at the Merge trigger automaticcaly generated
on the table, I found something interesting:
"if sessionproperty('replication_agent') = 1 and (select
trigger_nestlevel()) = 1"
Therfore, I've created my trigger like the following:
Create Trigger tg_Inserted On tblBlaBla FOR INSERT
AS
if not sessionproperty('replication_agent') = 1
return
Insert Into tblTest (Account_Code, Product_Code, DateCreation)
Select ins.Account_code, ins.Product_Code, GetDate()
From Inserted As Ins
I've done some test and everything works fine. However, before putting this
in Production, I was wondering if I absolutely need to put the "Select
trigger_nestlevel() ..." or not. I've read in the newsgroups and some are
saying you need to, some are saying you don't need to... Since it is a very
well documented feature, can anyone confirm me the proper way of doing this?
That would be greatly appreciated. Thanks.
|||Great. I'm not replicating this table. Thanks for the information.
"Kestutis Adomavicius" <kicker.lt@.noospaam_tut.by> wrote in message
news:eVz8BD8WFHA.1796@.TK2MSFTNGP15.phx.gbl...
> Nest level check allows to avoid ping-pong traffic from subscriber to
> publisher and vice versa
> But in your case that should matter only if you are also replicating table
> tblTest
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
>
> "Christian Hamel" <chamel@.NOSPAM.com> wrote in message
> news:udebeQ7WFHA.2692@.TK2MSFTNGP15.phx.gbl...
> Hello,
> I have a scenario where clients enter data into a MSDE local database
on
> their laptop. I would like to add a trigger on that table that fires only
> on the Server (SQL2K Ent.) when they are synchronizing when a new records
> has been inserted. By looking at the Merge trigger automaticcaly
generated
> on the table, I found something interesting:
> "if sessionproperty('replication_agent') = 1 and (select
> trigger_nestlevel()) = 1"
> Therfore, I've created my trigger like the following:
> Create Trigger tg_Inserted On tblBlaBla FOR INSERT
> AS
> if not sessionproperty('replication_agent') = 1
> return
> Insert Into tblTest (Account_Code, Product_Code, DateCreation)
> Select ins.Account_code, ins.Product_Code, GetDate()
> From Inserted As Ins
> I've done some test and everything works fine. However, before putting
this
> in Production, I was wondering if I absolutely need to put the "Select
> trigger_nestlevel() ..." or not. I've read in the newsgroups and some are
> saying you need to, some are saying you don't need to... Since it is a
very
> well documented feature, can anyone confirm me the proper way of doing
this?
> That would be greatly appreciated. Thanks.
>
|||I think it is to prevent recursive triggers from causing duplicate entries
in msmerge_contents. I could be wrong here.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Christian Hamel" <chamel@.NOSPAM.com> wrote in message
news:udebeQ7WFHA.2692@.TK2MSFTNGP15.phx.gbl...
> Hello,
> I have a scenario where clients enter data into a MSDE local database
on
> their laptop. I would like to add a trigger on that table that fires only
> on the Server (SQL2K Ent.) when they are synchronizing when a new records
> has been inserted. By looking at the Merge trigger automaticcaly
generated
> on the table, I found something interesting:
> "if sessionproperty('replication_agent') = 1 and (select
> trigger_nestlevel()) = 1"
> Therfore, I've created my trigger like the following:
> Create Trigger tg_Inserted On tblBlaBla FOR INSERT
> AS
> if not sessionproperty('replication_agent') = 1
> return
> Insert Into tblTest (Account_Code, Product_Code, DateCreation)
> Select ins.Account_code, ins.Product_Code, GetDate()
> From Inserted As Ins
> I've done some test and everything works fine. However, before putting
this
> in Production, I was wondering if I absolutely need to put the "Select
> trigger_nestlevel() ..." or not. I've read in the newsgroups and some are
> saying you need to, some are saying you don't need to... Since it is a
very
> well documented feature, can anyone confirm me the proper way of doing
this?
> That would be greatly appreciated. Thanks.
>

Merge replication of Foreign keys

Hi.
I need to add a new foreign key to a merge replicated table (It references
the PK in the same table). Is there anyway of replicating this to the other
subscribers without invalidating the snapshot or applying it separately on
each server?
AFAIK - no!
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"robham" <nospam@.co.uk> wrote in message
news:uXAUdaeiEHA.704@.TK2MSFTNGP12.phx.gbl...
> Hi.
> I need to add a new foreign key to a merge replicated table (It references
> the PK in the same table). Is there anyway of replicating this to the
other
> subscribers without invalidating the snapshot or applying it separately on
> each server?
>
|||Robham,
is the FK to be just a constraint? If so then I don't think it is possible
directly. I suppose you could use a combination of sp_repladdcolumn and
sp_repldropcolumn to achieve your aim but in some cases it is easier to
restart and do a noinit initialization.
If it is a new column, then sp_repladdcolumn should do it.
HTH,
Paul Ibison

Merge Replication not replicating updates

I have an issue that is only occurring in a production environment. The architecture is filtered merge replication between two SQL Server 2000 SP4 databases. The publisher is standard edition and the subscriber is personal edition.
The issue is that is I update certain rows on the subscriber the data is not replicated to the publisher. Inserts and deletes seem to replicate correctly. The issue is specific to certain rows in some tables. If I update other rows the updates replicate correctly. The subscription has been re-initialized once and it did not fix the issue. The replication process indicates that there was not data to merge and the subscriber updates remain and are at that point different form the publisher row values after the sync.
I can reproduce the issue by updating the row, running the sync process, and checking the publisher database. The synchronization process is executed using the merge agent ActiveX control.
This issue started occurring after a large conflict was generated during an earlier synch on this particular subscriber. We have other subscribing databases that are working fine.
I have already spent 8+ hours on the phone with TCS trying to solve this issue. If anyone has any ideas or has seen this type of issue before I would appreciate any direction to try to fix this issue.
Thanks

I ran another test today. I created a new database on a separate server and added a subscription to the publication and synced. The data came down correctly but my local updates to the specific rows where still ignored during the sync process.
I then updated the problem row in the publisher, synced to the new subscriber and now I can update the local row and it will sync back up to the publisher. Does anyone have any idea what happened to cause this?

|||

can you tell us what's specific about the columns/rows you're updating? Are you updating the primary key column? Are you updating a column that's moving in and out of a partition?

|||

There are actually 5 tables with 6 rows that if I update on the subscriber will not replicate to the publisher. These rows where all involved in a conflict at one time that was resolved. I setup a new database, subscriptions and synced and updates to these 5 rows will not propagate to the server.
I am updating a GUID field that is not the primary key and has no relation to the partition which is based on a join filter between these tables. The field I am updating is a last update key and its only purpose it to have a unique GUID that changes with each update. I can change other fields and the changes do not go to the publisher as well. The issue is definitely related to these rows as other rows will propagate to the publisher in the same tables.

Updating the row on the server seemed to fix one of the rows. The others are still broken.

Thanks for your help on this tricky issue.

|||

Since you say that creating a new subscription to this publication still faces the same problem, can you try this:

1. Run the snapshot agent at the publisher.

2. Create a new subscription to this publication

3. Synchronize this subscription

4. Try the updates at the subscriber and synchronize

5. See if your updates are sent or not.

|||I have tried this test and the updates for these specific rows do not replicate from the subscriber to the publisher.
|||

I have a question related to this issue:
I executed the sp_showreplicainfo stored procedure on the rows that will not update on the subscriber. The row info returned two rows. One with the server name set to the publisher database and another with the server name set to one of the subscribers (not the one I am testing with).
Is this expected behavior? The documentation on this is a bit thin.

|||

Hi Jeff , I'm having the same issue that you , but for me this start happeing after i install SP4.

I can't reinit all my suscriber (500+) , did you find the problem or a solution to this issue.

thxs. You can replay to my email at tutipedro@.hotmail.com

|||I am still working with Microsoft Technical support to try to find out why this happened. I did notices that when I update the rows that have the issue on the publisher side it seems to "unstick" the row and subscriber updates now work.

|||

Something interesting came up related to this issue while working with Microsoft tech support. I have twotables in my database that have a one-to-one relationship with each other. In the two tables the rowid is the primary key. This means that I have duplicate rowid values in different tables (The same rowid value is in 2 tables at the same time).
Could this have caused my issue? Is this a supported schema for replication?

|||

No is not an issue since the msmerge_contents include the article id table_nick.

|||Sorry - I posted this to the wrong thread - not sure how to delete

It seems like I've come accross the same issue this weekend (or something close) - that is, we are using merge replication on SQL2K SP4 - I wanted to increase a column size slightly so using a variation of the post on the Replication Answers website.

That is, store the data in a temp table, drop the column, re-add the column with the increase value, and then perform an update on the column - the first updates will make it to all the republisher and children. I've noticed that performing updates on this column for any value that was included in the first update does not propagate to the children. In the profiler, I can see the system procedure being called, but when one should field the new value it has "default".

What ended up being the issue is that we are using continuous replication so the skema changes got replicated to the subscribers before the snapshot finished running. What fixed the issue was to manual stop the merge agent, run the skema script, run the snapshot, and then sync. This time all was good.

-Ryan

|||

I have a question for you ..

run this query on your server

SELECT missing_cols, missing_col_count, * FROM sysmergearticles WHERE name LIKE '%<YOUR TABLE NAME>%'

Open the replication update triger on your server look out for this line of code

/* only do the map down when needed */

set @.missingbm = <SOME VALUE>

Are the missing_cols value equal to the @.missingbm in the trigger ?

|||Hello Pedro

I've got a similar problem, but changes from the publisher are not send to the subscriber after schema and datachanges. (No error message nor any conflicts indicated)

I've tried your instructions. And yes, I've got the same values (0x18). What does this mean? Can you explain it to me?

Thanks a lot
Aline
|||

Aline i'm short of time now a quick solution is , the replication triger for the tables that you know that have that problem should be the same in the susciber that in the server. Take the server (publisher) triger and run in the suscriber.

Merge Replication not replicating updates

I have an issue that is only occurring in a production environment. The architecture is filtered merge replication between two SQL Server 2000 SP4 databases. The publisher is standard edition and the subscriber is personal edition.
The issue is that is I update certain rows on the subscriber the data is not replicated to the publisher. Inserts and deletes seem to replicate correctly. The issue is specific to certain rows in some tables. If I update other rows the updates replicate correctly. The subscription has been re-initialized once and it did not fix the issue. The replication process indicates that there was not data to merge and the subscriber updates remain and are at that point different form the publisher row values after the sync.
I can reproduce the issue by updating the row, running the sync process, and checking the publisher database. The synchronization process is executed using the merge agent ActiveX control.
This issue started occurring after a large conflict was generated during an earlier synch on this particular subscriber. We have other subscribing databases that are working fine.
I have already spent 8+ hours on the phone with TCS trying to solve this issue. If anyone has any ideas or has seen this type of issue before I would appreciate any direction to try to fix this issue.
Thanks

I ran another test today. I created a new database on a separate server and added a subscription to the publication and synced. The data came down correctly but my local updates to the specific rows where still ignored during the sync process.
I then updated the problem row in the publisher, synced to the new subscriber and now I can update the local row and it will sync back up to the publisher. Does anyone have any idea what happened to cause this?

|||

can you tell us what's specific about the columns/rows you're updating? Are you updating the primary key column? Are you updating a column that's moving in and out of a partition?

|||

There are actually 5 tables with 6 rows that if I update on the subscriber will not replicate to the publisher. These rows where all involved in a conflict at one time that was resolved. I setup a new database, subscriptions and synced and updates to these 5 rows will not propagate to the server.
I am updating a GUID field that is not the primary key and has no relation to the partition which is based on a join filter between these tables. The field I am updating is a last update key and its only purpose it to have a unique GUID that changes with each update. I can change other fields and the changes do not go to the publisher as well. The issue is definitely related to these rows as other rows will propagate to the publisher in the same tables.

Updating the row on the server seemed to fix one of the rows. The others are still broken.

Thanks for your help on this tricky issue.

|||

Since you say that creating a new subscription to this publication still faces the same problem, can you try this:

1. Run the snapshot agent at the publisher.

2. Create a new subscription to this publication

3. Synchronize this subscription

4. Try the updates at the subscriber and synchronize

5. See if your updates are sent or not.

|||I have tried this test and the updates for these specific rows do not replicate from the subscriber to the publisher.
|||

I have a question related to this issue:
I executed the sp_showreplicainfo stored procedure on the rows that will not update on the subscriber. The row info returned two rows. One with the server name set to the publisher database and another with the server name set to one of the subscribers (not the one I am testing with).
Is this expected behavior? The documentation on this is a bit thin.

|||

Hi Jeff , I'm having the same issue that you , but for me this start happeing after i install SP4.

I can't reinit all my suscriber (500+) , did you find the problem or a solution to this issue.

thxs. You can replay to my email at tutipedro@.hotmail.com

|||I am still working with Microsoft Technical support to try to find out why this happened. I did notices that when I update the rows that have the issue on the publisher side it seems to "unstick" the row and subscriber updates now work.

|||

Something interesting came up related to this issue while working with Microsoft tech support. I have twotables in my database that have a one-to-one relationship with each other. In the two tables the rowid is the primary key. This means that I have duplicate rowid values in different tables (The same rowid value is in 2 tables at the same time).
Could this have caused my issue? Is this a supported schema for replication?

|||

No is not an issue since the msmerge_contents include the article id table_nick.

|||Sorry - I posted this to the wrong thread - not sure how to delete

It seems like I've come accross the same issue this weekend (or something close) - that is, we are using merge replication on SQL2K SP4 - I wanted to increase a column size slightly so using a variation of the post on the Replication Answers website.

That is, store the data in a temp table, drop the column, re-add the column with the increase value, and then perform an update on the column - the first updates will make it to all the republisher and children. I've noticed that performing updates on this column for any value that was included in the first update does not propagate to the children. In the profiler, I can see the system procedure being called, but when one should field the new value it has "default".

What ended up being the issue is that we are using continuous replication so the skema changes got replicated to the subscribers before the snapshot finished running. What fixed the issue was to manual stop the merge agent, run the skema script, run the snapshot, and then sync. This time all was good.

-Ryan

|||

I have a question for you ..

run this query on your server

SELECT missing_cols, missing_col_count, * FROM sysmergearticles WHERE name LIKE '%<YOUR TABLE NAME>%'

Open the replication update triger on your server look out for this line of code

/* only do the map down when needed */

set @.missingbm = <SOME VALUE>

Are the missing_cols value equal to the @.missingbm in the trigger ?

|||Hello Pedro

I've got a similar problem, but changes from the publisher are not send to the subscriber after schema and datachanges. (No error message nor any conflicts indicated)

I've tried your instructions. And yes, I've got the same values (0x18). What does this mean? Can you explain it to me?

Thanks a lot
Aline
|||

Aline i'm short of time now a quick solution is , the replication triger for the tables that you know that have that problem should be the same in the susciber that in the server. Take the server (publisher) triger and run in the suscriber.

Merge Replication not replicating updates

I have an issue that is only occurring in a production

environment. The architecture is filtered merge replication between two SQL

Server 2000 SP4 databases. The publisher is standard edition and the subscriber

is personal edition.

The issue is that is I update certain rows on the subscriber the data is not

replicated to the publisher. Inserts and deletes seem to replicate correctly.

The issue is specific to certain rows in some tables. If I update other rows

the updates replicate correctly. The subscription has been re-initialized once

and it did not fix the issue. The replication process indicates that there was

not data to merge and the subscriber updates remain and are at that point

different form the publisher row values after the sync.

I can reproduce the issue by updating the row, running the sync process, and

checking the publisher database. The synchronization process is executed using

the merge agent ActiveX control.

This issue started occurring after a large conflict was generated during an

earlier synch on this particular subscriber. We have other subscribing

databases that are working fine.

I have already spent 8+ hours on the phone with TCS trying to solve this issue.

If anyone has any ideas or has seen this type of issue before I would appreciate

any direction to try to fix this issue.

Thanks

I ran another test today. I created a new database on a separate

server and added a subscription to the publication and synced. The data came

down correctly but my local updates to the specific rows where still ignored

during the sync process.

I then updated the problem row in the publisher, synced to the new subscriber

and now I can update the local row and it will sync back up to the publisher.

Does anyone have any idea what happened to cause this?

|||

can you tell us what's specific about the columns/rows you're updating? Are you updating the primary key column? Are you updating a column that's moving in and out of a partition?

|||

There are actually 5 tables with 6 rows that if I update on

the subscriber will not replicate to the publisher. These rows where all

involved in a conflict at one time that was resolved. I setup a new database,

subscriptions and synced and updates to these 5 rows will not propagate to the

server.

I am updating a GUID field that is not the primary key and has no relation to

the partition which is based on a join filter between these tables. The field I

am updating is a last update key and its only purpose it to have a unique GUID

that changes with each update. I can change other fields and the changes do not

go to the publisher as well. The issue is definitely related to these rows as

other rows will propagate to the publisher in the same tables.

Updating the row on the server seemed to fix one of the

rows. The others are still broken.

Thanks for your help on this tricky issue.

|||

Since you say that creating a new subscription to this publication still faces the same problem, can you try this:

1. Run the snapshot agent at the publisher.

2. Create a new subscription to this publication

3. Synchronize this subscription

4. Try the updates at the subscriber and synchronize

5. See if your updates are sent or not.

|||I have tried this test and the updates for these specific rows do not replicate from the subscriber to the publisher.|||

I have a question related to this issue:

I executed the sp_showreplicainfo stored procedure on the rows that will not

update on the subscriber. The row info returned two rows. One with the server

name set to the publisher database and another with the server name set to one

of the subscribers (not the one I am testing with).

Is this expected behavior? The documentation on this is a bit thin.

|||

Hi Jeff , I'm having the same issue that you , but for me this start happeing after i install SP4.

I can't reinit all my suscriber (500+) , did you find the problem or a solution to this issue.

thxs. You can replay to my email at tutipedro@.hotmail.com

|||I am still working with Microsoft Technical support to try to find out why this happened. I did notices that when I update the rows that have the issue on the publisher side it seems to "unstick" the row and subscriber updates now work.|||

Something interesting came up related to this issue while

working with Microsoft tech support. I have twotables in my database that

have a one-to-one relationship with each other. In the two tables the rowid is the primary

key. This means that I have duplicate rowid values in different tables (The

same rowid value is in 2 tables at the same time).

Could this have caused my issue? Is this a supported schema for replication?

|||

No is not an issue since the msmerge_contents include the article id table_nick.

|||Sorry - I posted this to the wrong thread - not sure how to delete

It seems like I've come accross the same issue this weekend (or something close) - that is, we are using merge replication on SQL2K SP4 - I wanted to increase a column size slightly so using a variation of the post on the Replication Answers website.

That is, store the data in a temp table, drop the column, re-add the column with the increase value, and then perform an update on the column - the first updates will make it to all the republisher and children. I've noticed that performing updates on this column for any value that was included in the first update does not propagate to the children. In the profiler, I can see the system procedure being called, but when one should field the new value it has "default".

What ended up being the issue is that we are using continuous replication so the skema changes got replicated to the subscribers before the snapshot finished running. What fixed the issue was to manual stop the merge agent, run the skema script, run the snapshot, and then sync. This time all was good.

-Ryan|||

I have a question for you ..

run this query on your server

SELECT missing_cols, missing_col_count, * FROM sysmergearticles WHERE name LIKE '%<YOUR TABLE NAME>%'

Open the replication update triger on your server look out for this line of code

/* only do the map down when needed */

set @.missingbm = <SOME VALUE>

Are the missing_cols value equal to the @.missingbm in the trigger ?

|||Hello Pedro

I've got a similar problem, but changes from the publisher are not send to the subscriber after schema and datachanges. (No error message nor any conflicts indicated)

I've tried your instructions. And yes, I've got the same values (0x18). What does this mean? Can you explain it to me?

Thanks a lot
Aline|||

Aline i'm short of time now a quick solution is , the replication triger for the tables that you know that have that problem should be the same in the susciber that in the server. Take the server (publisher) triger and run in the suscriber.

Merge Replication not replicating updates

I have an issue that is only occurring in a production environment. The architecture is filtered merge replication between two SQL Server 2000 SP4 databases. The publisher is standard edition and the subscriber is personal edition.
The issue is that is I update certain rows on the subscriber the data is not replicated to the publisher. Inserts and deletes seem to replicate correctly. The issue is specific to certain rows in some tables. If I update other rows the updates replicate correctly. The subscription has been re-initialized once and it did not fix the issue. The replication process indicates that there was not data to merge and the subscriber updates remain and are at that point different form the publisher row values after the sync.
I can reproduce the issue by updating the row, running the sync process, and checking the publisher database. The synchronization process is executed using the merge agent ActiveX control.
This issue started occurring after a large conflict was generated during an earlier synch on this particular subscriber. We have other subscribing databases that are working fine.
I have already spent 8+ hours on the phone with TCS trying to solve this issue. If anyone has any ideas or has seen this type of issue before I would appreciate any direction to try to fix this issue.
Thanks

I ran another test today. I created a new database on a separate server and added a subscription to the publication and synced. The data came down correctly but my local updates to the specific rows where still ignored during the sync process.
I then updated the problem row in the publisher, synced to the new subscriber and now I can update the local row and it will sync back up to the publisher. Does anyone have any idea what happened to cause this?

|||

can you tell us what's specific about the columns/rows you're updating? Are you updating the primary key column? Are you updating a column that's moving in and out of a partition?

|||

There are actually 5 tables with 6 rows that if I update on the subscriber will not replicate to the publisher. These rows where all involved in a conflict at one time that was resolved. I setup a new database, subscriptions and synced and updates to these 5 rows will not propagate to the server.
I am updating a GUID field that is not the primary key and has no relation to the partition which is based on a join filter between these tables. The field I am updating is a last update key and its only purpose it to have a unique GUID that changes with each update. I can change other fields and the changes do not go to the publisher as well. The issue is definitely related to these rows as other rows will propagate to the publisher in the same tables.

Updating the row on the server seemed to fix one of the rows. The others are still broken.

Thanks for your help on this tricky issue.

|||

Since you say that creating a new subscription to this publication still faces the same problem, can you try this:

1. Run the snapshot agent at the publisher.

2. Create a new subscription to this publication

3. Synchronize this subscription

4. Try the updates at the subscriber and synchronize

5. See if your updates are sent or not.

|||I have tried this test and the updates for these specific rows do not replicate from the subscriber to the publisher.
|||

I have a question related to this issue:
I executed the sp_showreplicainfo stored procedure on the rows that will not update on the subscriber. The row info returned two rows. One with the server name set to the publisher database and another with the server name set to one of the subscribers (not the one I am testing with).
Is this expected behavior? The documentation on this is a bit thin.

|||

Hi Jeff , I'm having the same issue that you , but for me this start happeing after i install SP4.

I can't reinit all my suscriber (500+) , did you find the problem or a solution to this issue.

thxs. You can replay to my email at tutipedro@.hotmail.com

|||I am still working with Microsoft Technical support to try to find out why this happened. I did notices that when I update the rows that have the issue on the publisher side it seems to "unstick" the row and subscriber updates now work.

|||

Something interesting came up related to this issue while working with Microsoft tech support. I have twotables in my database that have a one-to-one relationship with each other. In the two tables the rowid is the primary key. This means that I have duplicate rowid values in different tables (The same rowid value is in 2 tables at the same time).
Could this have caused my issue? Is this a supported schema for replication?

|||

No is not an issue since the msmerge_contents include the article id table_nick.

|||Sorry - I posted this to the wrong thread - not sure how to delete

It seems like I've come accross the same issue this weekend (or something close) - that is, we are using merge replication on SQL2K SP4 - I wanted to increase a column size slightly so using a variation of the post on the Replication Answers website.

That is, store the data in a temp table, drop the column, re-add the column with the increase value, and then perform an update on the column - the first updates will make it to all the republisher and children. I've noticed that performing updates on this column for any value that was included in the first update does not propagate to the children. In the profiler, I can see the system procedure being called, but when one should field the new value it has "default".

What ended up being the issue is that we are using continuous replication so the skema changes got replicated to the subscribers before the snapshot finished running. What fixed the issue was to manual stop the merge agent, run the skema script, run the snapshot, and then sync. This time all was good.

-Ryan

|||

I have a question for you ..

run this query on your server

SELECT missing_cols, missing_col_count,*FROM sysmergearticles WHERE name LIKE'%<YOUR TABLE NAME>%'

Open the replication update triger on your server look out for this line of code

/* only do the map down when needed */

set @.missingbm = <SOME VALUE>

Are the missing_cols value equal to the @.missingbm in the trigger ?

|||Hello Pedro

I've got a similar problem, but changes from the publisher are not send to the subscriber after schema and datachanges. (No error message nor any conflicts indicated)

I've tried your instructions. And yes, I've got the same values (0x18). What does this mean? Can you explain it to me?

Thanks a lot
Aline
|||

Aline i'm short of time now a quick solution is , the replication triger for the tables that you know that have that problem should be the same in the susciber that in the server. Take the server (publisher) triger and run in the suscriber.

Merge Replication not replicating updates

I have an issue that is only occurring in a production

environment. The architecture is filtered merge replication between two SQL

Server 2000 SP4 databases. The publisher is standard edition and the subscriber

is personal edition.

The issue is that is I update certain rows on the subscriber the data is not

replicated to the publisher. Inserts and deletes seem to replicate correctly.

The issue is specific to certain rows in some tables. If I update other rows

the updates replicate correctly. The subscription has been re-initialized once

and it did not fix the issue. The replication process indicates that there was

not data to merge and the subscriber updates remain and are at that point

different form the publisher row values after the sync.

I can reproduce the issue by updating the row, running the sync process, and

checking the publisher database. The synchronization process is executed using

the merge agent ActiveX control.

This issue started occurring after a large conflict was generated during an

earlier synch on this particular subscriber. We have other subscribing

databases that are working fine.

I have already spent 8+ hours on the phone with TCS trying to solve this issue.

If anyone has any ideas or has seen this type of issue before I would appreciate

any direction to try to fix this issue.

Thanks

I ran another test today. I created a new database on a separate

server and added a subscription to the publication and synced. The data came

down correctly but my local updates to the specific rows where still ignored

during the sync process.

I then updated the problem row in the publisher, synced to the new subscriber

and now I can update the local row and it will sync back up to the publisher.

Does anyone have any idea what happened to cause this?

|||

can you tell us what's specific about the columns/rows you're updating? Are you updating the primary key column? Are you updating a column that's moving in and out of a partition?

|||

There are actually 5 tables with 6 rows that if I update on

the subscriber will not replicate to the publisher. These rows where all

involved in a conflict at one time that was resolved. I setup a new database,

subscriptions and synced and updates to these 5 rows will not propagate to the

server.

I am updating a GUID field that is not the primary key and has no relation to

the partition which is based on a join filter between these tables. The field I

am updating is a last update key and its only purpose it to have a unique GUID

that changes with each update. I can change other fields and the changes do not

go to the publisher as well. The issue is definitely related to these rows as

other rows will propagate to the publisher in the same tables.

Updating the row on the server seemed to fix one of the

rows. The others are still broken.

Thanks for your help on this tricky issue.

|||

Since you say that creating a new subscription to this publication still faces the same problem, can you try this:

1. Run the snapshot agent at the publisher.

2. Create a new subscription to this publication

3. Synchronize this subscription

4. Try the updates at the subscriber and synchronize

5. See if your updates are sent or not.

|||I have tried this test and the updates for these specific rows do not replicate from the subscriber to the publisher.|||

I have a question related to this issue:

I executed the sp_showreplicainfo stored procedure on the rows that will not

update on the subscriber. The row info returned two rows. One with the server

name set to the publisher database and another with the server name set to one

of the subscribers (not the one I am testing with).

Is this expected behavior? The documentation on this is a bit thin.

|||

Hi Jeff , I'm having the same issue that you , but for me this start happeing after i install SP4.

I can't reinit all my suscriber (500+) , did you find the problem or a solution to this issue.

thxs. You can replay to my email at tutipedro@.hotmail.com

|||I am still working with Microsoft Technical support to try to find out why this happened. I did notices that when I update the rows that have the issue on the publisher side it seems to "unstick" the row and subscriber updates now work.|||

Something interesting came up related to this issue while

working with Microsoft tech support. I have twotables in my database that

have a one-to-one relationship with each other. In the two tables the rowid is the primary

key. This means that I have duplicate rowid values in different tables (The

same rowid value is in 2 tables at the same time).

Could this have caused my issue? Is this a supported schema for replication?

|||

No is not an issue since the msmerge_contents include the article id table_nick.

|||Sorry - I posted this to the wrong thread - not sure how to delete

It seems like I've come accross the same issue this weekend (or something close) - that is, we are using merge replication on SQL2K SP4 - I wanted to increase a column size slightly so using a variation of the post on the Replication Answers website.

That is, store the data in a temp table, drop the column, re-add the column with the increase value, and then perform an update on the column - the first updates will make it to all the republisher and children. I've noticed that performing updates on this column for any value that was included in the first update does not propagate to the children. In the profiler, I can see the system procedure being called, but when one should field the new value it has "default".

What ended up being the issue is that we are using continuous replication so the skema changes got replicated to the subscribers before the snapshot finished running. What fixed the issue was to manual stop the merge agent, run the skema script, run the snapshot, and then sync. This time all was good.

-Ryan|||

I have a question for you ..

run this query on your server

SELECT missing_cols, missing_col_count, * FROM sysmergearticles WHERE name LIKE '%<YOUR TABLE NAME>%'

Open the replication update triger on your server look out for this line of code

/* only do the map down when needed */

set @.missingbm = <SOME VALUE>

Are the missing_cols value equal to the @.missingbm in the trigger ?

|||Hello Pedro

I've got a similar problem, but changes from the publisher are not send to the subscriber after schema and datachanges. (No error message nor any conflicts indicated)

I've tried your instructions. And yes, I've got the same values (0x18). What does this mean? Can you explain it to me?

Thanks a lot
Aline|||

Aline i'm short of time now a quick solution is , the replication triger for the tables that you know that have that problem should be the same in the susciber that in the server. Take the server (publisher) triger and run in the suscriber.

Merge replication missing transactions

I have 2 servers, one running SQL 2000 and one running SQL 7. On the 2000 box I have 2 databases which are replicating between each other fine using Transactional replication. (One way replication only)

I also wish to use replication to keep a database on the SQL 7 box up to date. (Again the dataflow is ALL one way between the 3 databases)

I have set up Merge replication between these two due to transactional replication not working correctly between the different versions of SQL Server. (I belive this is due to SQL 7 using a date stamp as the unique ID on the table columns and 2000 using a GUID.)

Now whenever I issue an insert/update/delete to the first database in the chain, transactional replication updates the 2nd ok, but merge replication then fails to update the database on the 3rd server.

If I issue an insert/update/delete to the 2nd database in the chain the change is replicated correctly.

Any ideas?...Upgrade SQL2k to SP3. Microsoft have updated this but didn't publicise it at all!

If anyone has any problems with this email me at my username @.hotmail.com.

Cheers,|||Upgrade SQL2k to SP3. Microsoft have updated this but didn't publicise it at all!

If anyone has any problems with this email me at my username @.hotmail.com.

Cheers,

Merge replication error - invalid column name 'rowguidcol'

Hi,

I'm having dramas with a merge replication between two servers. They have been replicating information between three databases happily for about 18 months. Recently I had to do an upgrade on the databases, so I deleted the subscriptions and the snapshots, applied the upgrade script and recreated the snapshots and subscriptions.

Now when they go to replicate, the merge agent for each subscription gives the error "invalid column name 'rowguidcol'".

From some investigation, I think this has something to do with the fact that as they used to replicate, the subscriber has the schema information from the old snapshot, and doesn't recognise the new one. I can't reinitialise the schema from the publisher as not all the data in the databases is replicated, so I can't have the publisher overwrite the subscriber.

What can I do in this situation?

Regards,
James

Can you explain what "upgrade on the databases" is? What columns/rows were updated? And how did you recreate the publication, snapshot and subscriptions, via scripts or UI? Did you reinitialize the subscription, regenerate the snapshot, dynamic snapshot, and synchronize?

|||Hi,

Sorry. The databases are part of a SQL-based application called Amlib. It's a library database. I work at a school and we use Amlib for our library cataloging. The application was running at verion 4.2 and the "upgrade" was to 5.1. The three main databases each had extra tables added to them as part of the upgrade. I can give you a run-down of what actually changed if you think it will help.

I recreated the publication, snapshot and subscriptions via Enterprise Manager. Same way in which I created them the first time. I had to delete the snapshots and subscriptions to perform the update on the databases.

I didn't reinitialise the subscription, as I understood that would regenerate the schema and push the data out to the subscriber. I can't go down that path as there is data which is unique to the databases on each server and therefore is not replicated. Also, there's quite a lot of data (4GB) and the WAN link between the two servers wouldn't cope with the transfer.

I'm afraid I don't know what dynamic snapshot is.

Regards,
James
|||

Did the upgrade touch the existing tables that were part of replication? I would assume so since you had to remove replication. do you know if this upgrade removed, dropped or added any objects, columns, stored procedures etc. that might interfere with replication? How about any rows?

Is this SQL 2000 or SQL 2005? Did you use the wizards to set up a no-sync subscription? If this is SQL 2005, you can follow the steps in topic "Initializing a Merge Subscription Without a Snapshot".

|||Actually I don't know. I don't believe that any data was changed - I just know that extra tables were added to the databases. I think there were some extra rows added to existing tables, yes.

Although to be honest, I thought I had to break the replication regardless, because you can't modify an existing snapshot without re-creating the snapshot? That's what I believed to be true anyway.

As you can probably tell, I'm not much of a SQL guru..... :-)

It's running on SQL 2000 unfortunately, not 2005. And yes, I set up the snapshots and subscriptions using the wizard in Enterprise Manager
|||Since you added new data to existing tables that are published, I assume you want those changes at the subscriber as well. What I'd do is just recreate the publication, subscriptions, regenerate the snapshot and apply the new snapshot to the subscriber. Basically, start from scratch.|||
I did start from scratch! The the snapshot, publications and subscriptions are all brand new. The problem is that there is existing data at the other end which can't be overwritten, so I can't simply re-initialise the schema/data. I just need to find a way of getting the databases replicating again....
|||

hey ,

simply check if all ur rowguid columns (in published tables) have their default set to newid() , set them up if not and hopefully ur problem will be solved..

|||

i had hear someone got such problem as well and

finally solved the problem.

pls try to build a "remote scripting" tool into your software.

This allowed you to manually recreate the new tables at the subscribers.

hope that will help you to solve your problem.

that Dynamic snapshot is not reliable when it comes
to table changes or additions...

|||

If you do not wish to lose your subscriber's data, I would say backup your tables/database. Re-setup the subscription and let the data get overwritten. Then do a diff between the current data and the back and do an insert/update/delete of the relevant rows and they should then propagate to the publisher. Agreed that this may not be an elegant solution, but it will achieve what you want.

Another thing I can think of is that the subscriber propbably does not have the rowguid column. You are doing a no-sync subscription (which means the subscriber already has schema and data). If that is the case, you would need to create this new rowguid column at the subscriber and populate the values to be equal to those on the publisher for each row for each table and then do a synchronize. Hopefully that maybe another option for you.

But both of them are not pretty.

Merge replication error - invalid column name 'rowguidcol'

Hi,

I'm having dramas with a merge replication between two servers. They have been replicating information between three databases happily for about 18 months. Recently I had to do an upgrade on the databases, so I deleted the subscriptions and the snapshots, applied the upgrade script and recreated the snapshots and subscriptions.

Now when they go to replicate, the merge agent for each subscription gives the error "invalid column name 'rowguidcol'".

From some investigation, I think this has something to do with the fact that as they used to replicate, the subscriber has the schema information from the old snapshot, and doesn't recognise the new one. I can't reinitialise the schema from the publisher as not all the data in the databases is replicated, so I can't have the publisher overwrite the subscriber.

What can I do in this situation?

Regards,
James

Can you explain what "upgrade on the databases" is? What columns/rows were updated? And how did you recreate the publication, snapshot and subscriptions, via scripts or UI? Did you reinitialize the subscription, regenerate the snapshot, dynamic snapshot, and synchronize?

|||Hi,

Sorry. The databases are part of a SQL-based application called Amlib. It's a library database. I work at a school and we use Amlib for our library cataloging. The application was running at verion 4.2 and the "upgrade" was to 5.1. The three main databases each had extra tables added to them as part of the upgrade. I can give you a run-down of what actually changed if you think it will help.

I recreated the publication, snapshot and subscriptions via Enterprise Manager. Same way in which I created them the first time. I had to delete the snapshots and subscriptions to perform the update on the databases.

I didn't reinitialise the subscription, as I understood that would regenerate the schema and push the data out to the subscriber. I can't go down that path as there is data which is unique to the databases on each server and therefore is not replicated. Also, there's quite a lot of data (4GB) and the WAN link between the two servers wouldn't cope with the transfer.

I'm afraid I don't know what dynamic snapshot is.

Regards,
James
|||

Did the upgrade touch the existing tables that were part of replication? I would assume so since you had to remove replication. do you know if this upgrade removed, dropped or added any objects, columns, stored procedures etc. that might interfere with replication? How about any rows?

Is this SQL 2000 or SQL 2005? Did you use the wizards to set up a no-sync subscription? If this is SQL 2005, you can follow the steps in topic "Initializing a Merge Subscription Without a Snapshot".

|||Actually I don't know. I don't believe that any data was changed - I just know that extra tables were added to the databases. I think there were some extra rows added to existing tables, yes.

Although to be honest, I thought I had to break the replication regardless, because you can't modify an existing snapshot without re-creating the snapshot? That's what I believed to be true anyway.

As you can probably tell, I'm not much of a SQL guru..... :-)

It's running on SQL 2000 unfortunately, not 2005. And yes, I set up the snapshots and subscriptions using the wizard in Enterprise Manager
|||Since you added new data to existing tables that are published, I assume you want those changes at the subscriber as well. What I'd do is just recreate the publication, subscriptions, regenerate the snapshot and apply the new snapshot to the subscriber. Basically, start from scratch.|||
I did start from scratch! The the snapshot, publications and subscriptions are all brand new. The problem is that there is existing data at the other end which can't be overwritten, so I can't simply re-initialise the schema/data. I just need to find a way of getting the databases replicating again....
|||

hey ,

simply check if all ur rowguid columns (in published tables) have their default set to newid() , set them up if not and hopefully ur problem will be solved..

|||

i had hear someone got such problem as well and

finally solved the problem.

pls try to build a "remote scripting" tool into your software.

This allowed you to manually recreate the new tables at the subscribers.

hope that will help you to solve your problem.

that Dynamic snapshot is not reliable when it comes
to table changes or additions...

|||

If you do not wish to lose your subscriber's data, I would say backup your tables/database. Re-setup the subscription and let the data get overwritten. Then do a diff between the current data and the back and do an insert/update/delete of the relevant rows and they should then propagate to the publisher. Agreed that this may not be an elegant solution, but it will achieve what you want.

Another thing I can think of is that the subscriber propbably does not have the rowguid column. You are doing a no-sync subscription (which means the subscriber already has schema and data). If that is the case, you would need to create this new rowguid column at the subscriber and populate the values to be equal to those on the publisher for each row for each table and then do a synchronize. Hopefully that maybe another option for you.

But both of them are not pretty.

Merge replication error - invalid column name 'rowguidcol'

Hi,

I'm having dramas with a merge replication between two servers. They have been replicating information between three databases happily for about 18 months. Recently I had to do an upgrade on the databases, so I deleted the subscriptions and the snapshots, applied the upgrade script and recreated the snapshots and subscriptions.

Now when they go to replicate, the merge agent for each subscription gives the error "invalid column name 'rowguidcol'".

From some investigation, I think this has something to do with the fact that as they used to replicate, the subscriber has the schema information from the old snapshot, and doesn't recognise the new one. I can't reinitialise the schema from the publisher as not all the data in the databases is replicated, so I can't have the publisher overwrite the subscriber.

What can I do in this situation?

Regards,
James

Can you explain what "upgrade on the databases" is? What columns/rows were updated? And how did you recreate the publication, snapshot and subscriptions, via scripts or UI? Did you reinitialize the subscription, regenerate the snapshot, dynamic snapshot, and synchronize?

|||Hi,

Sorry. The databases are part of a SQL-based application called Amlib. It's a library database. I work at a school and we use Amlib for our library cataloging. The application was running at verion 4.2 and the "upgrade" was to 5.1. The three main databases each had extra tables added to them as part of the upgrade. I can give you a run-down of what actually changed if you think it will help.

I recreated the publication, snapshot and subscriptions via Enterprise Manager. Same way in which I created them the first time. I had to delete the snapshots and subscriptions to perform the update on the databases.

I didn't reinitialise the subscription, as I understood that would regenerate the schema and push the data out to the subscriber. I can't go down that path as there is data which is unique to the databases on each server and therefore is not replicated. Also, there's quite a lot of data (4GB) and the WAN link between the two servers wouldn't cope with the transfer.

I'm afraid I don't know what dynamic snapshot is.

Regards,
James
|||

Did the upgrade touch the existing tables that were part of replication? I would assume so since you had to remove replication. do you know if this upgrade removed, dropped or added any objects, columns, stored procedures etc. that might interfere with replication? How about any rows?

Is this SQL 2000 or SQL 2005? Did you use the wizards to set up a no-sync subscription? If this is SQL 2005, you can follow the steps in topic "Initializing a Merge Subscription Without a Snapshot".

|||Actually I don't know. I don't believe that any data was changed - I just know that extra tables were added to the databases. I think there were some extra rows added to existing tables, yes.

Although to be honest, I thought I had to break the replication regardless, because you can't modify an existing snapshot without re-creating the snapshot? That's what I believed to be true anyway.

As you can probably tell, I'm not much of a SQL guru..... :-)

It's running on SQL 2000 unfortunately, not 2005. And yes, I set up the snapshots and subscriptions using the wizard in Enterprise Manager
|||Since you added new data to existing tables that are published, I assume you want those changes at the subscriber as well. What I'd do is just recreate the publication, subscriptions, regenerate the snapshot and apply the new snapshot to the subscriber. Basically, start from scratch.|||
I did start from scratch! The the snapshot, publications and subscriptions are all brand new. The problem is that there is existing data at the other end which can't be overwritten, so I can't simply re-initialise the schema/data. I just need to find a way of getting the databases replicating again....
|||

hey ,

simply check if all ur rowguid columns (in published tables) have their default set to newid() , set them up if not and hopefully ur problem will be solved..

|||

i had hear someone got such problem as well and

finally solved the problem.

pls try to build a "remote scripting" tool into your software.

This allowed you to manually recreate the new tables at the subscribers.

hope that will help you to solve your problem.

that Dynamic snapshot is not reliable when it comes
to table changes or additions...

|||

If you do not wish to lose your subscriber's data, I would say backup your tables/database. Re-setup the subscription and let the data get overwritten. Then do a diff between the current data and the back and do an insert/update/delete of the relevant rows and they should then propagate to the publisher. Agreed that this may not be an elegant solution, but it will achieve what you want.

Another thing I can think of is that the subscriber propbably does not have the rowguid column. You are doing a no-sync subscription (which means the subscriber already has schema and data). If that is the case, you would need to create this new rowguid column at the subscriber and populate the values to be equal to those on the publisher for each row for each table and then do a synchronize. Hopefully that maybe another option for you.

But both of them are not pretty.

Merge Replication DataBase File Size

Hi,
Currently we are merge replicating more than 20 databases , One server
is at our end other one is far away. we are having our end Server as
Subscriber as other one as Publisher.
During each replication first we set up the Publisher at other end and after
the snapshot is over we truncate the log file and then take the backup of
Publisher database and ZIP the backup file and download to our end(Subsciber)
through FTP.
But it takes a Long time to download is there is any other way to reduce the
file size, what is the best way to handle this.
Please give me a solution as soon as Possible.
Thanks,
Herbert
This is probably the best way to do it. You can also have a look at the copy
subscription method if your database is less than 2 Gigs.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Herbert" <Herbert@.discussions.microsoft.com> wrote in message
news:7CBAD562-2C10-4A9C-AB3D-3B634F72B89F@.microsoft.com...
> Hi,
> Currently we are merge replicating more than 20 databases , One server
> is at our end other one is far away. we are having our end Server as
> Subscriber as other one as Publisher.
> During each replication first we set up the Publisher at other end and
after
> the snapshot is over we truncate the log file and then take the backup of
> Publisher database and ZIP the backup file and download to our
end(Subsciber)
> through FTP.
> But it takes a Long time to download is there is any other way to reduce
the
> file size, what is the best way to handle this.
> Please give me a solution as soon as Possible.
> Thanks,
> Herbert