Showing posts with label level. Show all posts
Showing posts with label level. Show all posts

Wednesday, March 21, 2012

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.

Saturday, February 25, 2012

Default Values properties (table level) not working.


I am using SQL Server Management Studio Express (SSMSE) with SQL Server Express as my database tools/database to assign the ‘Default Value’ for a column at the table level.

Going over the basics… using the database tools (SSMSE) and when inserting a new row; all rows by default have a 'Null' value. Ok.
If a default value is assigned to a column (table level) using the database tools, the default value is inserted correctly if that column has a null value upon the creation of a new row. Ok.

This works fine when I am working with SSMSE on tables (inserting, deleting editing rows etc.) within my database…

But this doesn’t apply or work for adding new rows with datasets (example: using the default insert, update, delete statements provided by the wizard and using a DataGridView). My table level default values are not inserted into the new row, instead my column that had a default value assigned; now has a 'Null' value in the new row that was created by the dataset.

Isn’t a Null value is still a Null value for a new row?

Shouldn’t the database engine supply that ‘default value’ for a field that had a ‘Null’ value upon row creation?

I have always thought of a table level column ‘Default Value property’ as a trigger that tests for nulls and inserts the default value if that column has a null value when the new row is created. So I am expecting the database engine to insert the default value for that column, not the dataset when the value inserted into that column is null for a new row. I really don't need a (table level) column default property that only works with database tools for inserting new rows, that doesn't help me... totally baffled here...
Thanks

Hey Rick.

Default values will be applied to a column when NO explicit value is specified for the column in the corresponding insert (this includes a <NULL> explicit value)...so, for example, assume I have a table with 2 columns, colA and colB, and on colB I have a default value of 'colBDefault' specified...the following statement will end up with a record that includes a row with 'colAvalue' for colA, and null for colB, because I am explicitly saying to use a null value for colB:

insert table (colA, colB) select 'colAvalue', null

However, the following statement will end up with a value of 'colAvalue' for colA, and the default value of 'colBDefault' for colB, because no explicit value is specified for colB:

insert table (colA) select 'colAvalue'

I'd bet that the DataGridView is specifying all columns with a null value for anything you don't specify. To prove this, you could run a trace on the Sql server to see what the actual insert command being executed is...

HTH,

|||Hello Chad,

Thanks for the reply. That did help.

Unfortunately I couldn't get the ADO.Net trace logging to work... my tracing abilities are pretty much nil...

Another way to look at this is I am only pulling certain text fields that I want (no default value assigned) from the adapter / dataset for that table, not all of the fields from that particlular table.
The fields that I have designated a default value for are not included in the dataset, so they do not have an insert command etc. (or value assigned) for those fields for that table.
But... those fields that are *not* included in the insert statement etc. for that table do in fact show a value of 'Null' for the new row even though they have a default value assigned for them at the table level...

Example:
Fields: (ID), (LastName), (FirstName), ((Age) - default value set to 0), ((DeptNo) - default set to 100)

The adapter is only pulling fields: (ID), (LastName) and (FirstName); the insert etc. commands only pertain to those fields.
When a new row is inserted fields: (Age) and (DeptNo) do show a 'Null' value, not their assigned default value.

Thanks,
Rick

|||Whooooops...

My apologies!

It does work as you suggested!
I literally had six different forms to test things and simply got them mixed up, of what worked and what didn't!!!

Thanks,
Rick

Friday, February 17, 2012

Default SQL 2000 Compatability Level problem

I have a SQL 200 server that creates all new databases in compatability level
65. This is creating problems for an application that requires level 80 to
create and populate. How do I change the default level for any new databases?
Chris Millette
MCP/Network Administrator
Community Bank & Trust
The process that creates the database deletes it if it cannot complete the
entire process. I did find a scipt that changes the model db level and that
resolved the issue.
Chris Millette
MCP/Network Administrator
Community Bank & Trust
"Hari Prasad" wrote:
[vbcol=seagreen]
> Change the compatibility level of Model database to 80; after that what ever
> database you create newly
> the compatibility level will be 80.
> Thanks
> Hari
> "Millette" wrote:

Default SQL 2000 Compatability Level problem

I have a SQL 200 server that creates all new databases in compatability level
65. This is creating problems for an application that requires level 80 to
create and populate. How do I change the default level for any new databases?
--
Chris Millette
MCP/Network Administrator
Community Bank & TrustChange the compatibility level of Model database to 80; after that what ever
database you create newly
the compatibility level will be 80.
Thanks
Hari
"Millette" wrote:
> I have a SQL 200 server that creates all new databases in compatability level
> 65. This is creating problems for an application that requires level 80 to
> create and populate. How do I change the default level for any new databases?
> --
> Chris Millette
> MCP/Network Administrator
> Community Bank & Trust|||The process that creates the database deletes it if it cannot complete the
entire process. I did find a scipt that changes the model db level and that
resolved the issue.
--
Chris Millette
MCP/Network Administrator
Community Bank & Trust
"Hari Prasad" wrote:
> Change the compatibility level of Model database to 80; after that what ever
> database you create newly
> the compatibility level will be 80.
> Thanks
> Hari
> "Millette" wrote:
> > I have a SQL 200 server that creates all new databases in compatability level
> > 65. This is creating problems for an application that requires level 80 to
> > create and populate. How do I change the default level for any new databases?
> > --
> > Chris Millette
> > MCP/Network Administrator
> > Community Bank & Trust

Default SQL 2000 Compatability Level problem

I have a SQL 200 server that creates all new databases in compatability leve
l
65. This is creating problems for an application that requires level 80 to
create and populate. How do I change the default level for any new databases
?
--
Chris Millette
MCP/Network Administrator
Community Bank & TrustChange the compatibility level of Model database to 80; after that what ever
database you create newly
the compatibility level will be 80.
Thanks
Hari
"Millette" wrote:

> I have a SQL 200 server that creates all new databases in compatability le
vel
> 65. This is creating problems for an application that requires level 80 to
> create and populate. How do I change the default level for any new databas
es?
> --
> Chris Millette
> MCP/Network Administrator
> Community Bank & Trust|||The process that creates the database deletes it if it cannot complete the
entire process. I did find a scipt that changes the model db level and that
resolved the issue.
--
Chris Millette
MCP/Network Administrator
Community Bank & Trust
"Hari Prasad" wrote:
[vbcol=seagreen]
> Change the compatibility level of Model database to 80; after that what ev
er
> database you create newly
> the compatibility level will be 80.
> Thanks
> Hari
> "Millette" wrote:
>