Delay for Conflict Resolution in SS2K5

I have a couple of tables set up with column level tracking and using the "Subscriber Always Wins" conflict resolver.

I am still trying to work out why there is a conflict as the only updates to these rows happen at the subscriber.

What I am finding is that a conflict occurs and there appears to be a delay between the conflict being recognised and then resolved.

The reason I know there is a delay is because this is playing havoc with a data extract that relies on the updates from the subscriber.

For instance, I have a job on which the status is changed. That status change triggers an extract via BizTalk to another system. BizTalk, via an SQL adapter extracts the data from the server and I find that some of it is missing in the extract.

I go and look into the database at the raw data and find that the data is in fact there.

I have certain triggers running which set up export flags in the database to say this data should be exported. This works perfectly when there are no conflicts.

In each case where data has not been extracted, a conflict occurs.

Is there any way to guarantee that the conflict will be resolved at the same time as the synchronisation is complete - i.e. within the same transaction?

I thought replication was supposed to be a single transaction - you get it all or you get nothing.

I'm interested to hear from anyone who has experienced this behaviour.

Thanks

Are you saying that when you run merge agent, there happens a conflict and that conflict is not resolved in the same merge session?

Please explain your scenario more clearly so that we can troubleshoot it.

Also if you could simplify and narrow down the failure, it will be helpful.

|||There is another post on here that details the conflicts we are getting. It drills into some of the details

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=540159&SiteID=1

Just to clarify, the subscribers we have are all from SQL Mobile.

When the status data gets synchronised, triggers operate on the update/insert to create a record to indicate that the data should be exported from the system. BizTalk is responsible for extracting this data and looks into SQL every ten seconds for data to extract.

I am getting, on occasion, data that is incomplete. Whenever this occurs, the incomplete data is always from one of the two tables I have that are getting conflicts (see other post for this particular problem). When I go back and look at the data in the database, I see what I would have expected the extract process to get.

This to me indicates that there is a delay in the conflict resolution. (Custom - subscriber always wins).

Let me know what you need if this is not enough.

Defining the Scope of SCOPE_IDENTITY

A couple of Web applications in different SQL Server 2000 databases use SCOPE_IDENTITY to retrieve the key value of a record that was just inserted. It works--most of the time. However, from time to time the identity value is not retrieved. Evidence suggests that in these cases, a null value is being retrieved. This has forced me to come up with less-than-ideal workarounds for the missing identity value.

Does anyone have any idea why SCOPE_IDENTITY sometimes fails to retrieve the identity value and transmit it back to the Web page? Could a network issue cause the problem? Is there anything I can do other than rewrite the apps to use a different algorithm than using SCOPE_IDENTITY? Thanks.

I am not aware of any issues with SCOPE_IDENTITY(); this might be an application / connection issue and not a problem with SCOPE_IDENTITY(). I am certainly interested in the outcome of this. Can somebody please check me on this?|||

If you are using embedded SQL in your application it might be worth placing this logic into a stored procedure and calling that from your application. That should avoid any comms problems as the procedure will run or not run as a single call (and not have a problem between statements in the operation).

|||

Yes, the web app uses embedded SQL in classic ASP. The application was written in classic ASP and there has never been a good reason to rewrite it. The web app is the only application that performs DML on the table--there are no separate triggers or other ways into the table.

How could an embedded SQL statement in a single Web page cause scope problems? One Web page consulted during the research on this problem said this situation should be treated as a single scope.

I will probably try the stored procedure method. But I am curious as to why all sources practically demand that SCOPE_IDENTITY be used within a stored procedure when it is allowed to work in other situations.

Thanks for the input.

Default value in textboxes are lost when a drop down does a post b

We have a couple of dropdown boxes and a text field as parameters to a report.
The options in the second dropdown box depends on the selection of the first
one, so I'm happy with the fact that a post back occurs when the selected
option in dropdown box 1 is changed.
However the value entered by the user in the text box get overriden by the
default value, that I'm not too happy with.
Is there a way of preserving user input?
Fred.
--
FredFred, have you tried NOT setting a default for the second parameter?
If that doesn't work then I think the answer is no!
Chris
Fred wrote:
> We have a couple of dropdown boxes and a text field as parameters to
> a report.
> The options in the second dropdown box depends on the selection of
> the first one, so I'm happy with the fact that a post back occurs
> when the selected option in dropdown box 1 is changed.
> However the value entered by the user in the text box get overriden
> by the default value, that I'm not too happy with.
> Is there a way of preserving user input?
> Fred.