Hexadecimal condition check and Identity columns

hi , i am using transactional replication between two Sql server 2000 . my
tables have identity columns as the primary keys with the identity property
set to Yes( not for replication). Now when I am generating the replication
intrinsic stored procs for the subscriber , I have a problem with the update
stored procs which are generated at the subscriber side. Each of these Update
command SPs ( which are each for a table) have two update statements in them
and a IF statement which chooses one of the udpate statements to run
depending on a binary hexa decimal field. If the condition satifies , it run
the first update query which unlike the second update query updates the
identity column as well and this update query is always selected by the
Update statement to run. The second if stement is run when the hexadicmal
conditions is not met and the funny part is that it never ever happens. I had
to comment out the part of the first update query which tried to update the
identity column. Now my queston are
1.why is replication trying to update the identity columns when it know
that they can not be updated.
2.What is the binary hexadecimal field used for, why is this the condition
in each and every case select statement in every field?
Please help me with this hexadecimal paradigm
The IF statement checks to see if the PK is being updated, and if so
executes the update statement differently. This is not related to identity
columns. If you have an identity column on the subscriber, compilation of
this procedure may fail. That's because the identity attribute shouldn't be
there - it's implicitly treated as read-only. If you had queued updating
subscribers the logic in these sps is different and there is no update or
insert into the identity columns because the identity attribute is expected
on the subscriber.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

heterogeneous replication

how can i make a replication between SQl Server 2000 and Oracle 9i
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
sure can. Follow the advise you see in this link.
http://www.nwsu.com/lowres_Replication_Ch02.pdf
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Saul Ernesto Martinez Gutierrez" <quetin81@.yahoo.com.mx> wrote in message
news:uJjNrmKvEHA.2200@.TK2MSFTNGP11.phx.gbl...
>
> how can i make a replication between SQl Server 2000 and Oracle 9i
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!

Help-me merge replication

Good morning.

I have a big problem with merge replication.

This a scenary.

I have one database SQL 2000 in my server, and one aplication in PDA with SQL CE, but a read very turorials and always ask for a developer another aplication for a sincronization !

Exists one control in SQL CE for this ?

[]'s

You're in the wrong place. try the Replication forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=90&SiteID=1

-Jamie

|||Sorry

Help: Replication stops with no error or warnings!

hi all,
I have sql server 2005 sp2 running transactional replication between 2
production servers on different domains. Every once in a while
transaction stop being delivered to the target with no warnings or
errors being generated by any of the servers involved. Using
replication monitor on the the publisher and viewing the tab "
Publisher to Distributor" shows transactions being delivered
successfully ("n transaction(s) with n command(s) were delivered
successfully") but the transactions do not show up on the target
server?
Any thoughts much appreciated as the only resolution i've found is to
wait until off hours and reinitialize the subscriptions. i'm going to
have to put a custom alert system in place to check table counts but i
really need to find the cause of this.
-Thanks! DF
Difficult to tell exactly what is getting replicated in repl monitor. Best
tool to troubleshoot is to run profiler on subscriber and see if you can find
anything. Best to do after hours if you can repeat problem w/ just you as
user.
What is your distribution agent profile? How did you initialize subscriber -
snapshot agent or backup/restore? If backup init - make sure you disable
triggers or set to NFR and drop FK's at subscriber. Perhaps your agent is
ignoring errors caused by FK constraints and not delivering rows changes...
ChrisB MCDBA
MSSQLConsulting.com
"dfateman@.yahoo.com" wrote:

> hi all,
> I have sql server 2005 sp2 running transactional replication between 2
> production servers on different domains. Every once in a while
> transaction stop being delivered to the target with no warnings or
> errors being generated by any of the servers involved. Using
> replication monitor on the the publisher and viewing the tab "
> Publisher to Distributor" shows transactions being delivered
> successfully ("n transaction(s) with n command(s) were delivered
> successfully") but the transactions do not show up on the target
> server?
> Any thoughts much appreciated as the only resolution i've found is to
> wait until off hours and reinitialize the subscriptions. i'm going to
> have to put a custom alert system in place to check table counts but i
> really need to find the cause of this.
> -Thanks! DF
>

HELP: MSmerge_past_partition_mappings is Huge !

I have a SQL 2005 Merge Replication setup with SQL Mobile Subscribers. The
merge replication performance has been incredibly slow (a couple of hours in
some cases). I looked at the size of some the Replication tables and their
sizes are huge compared with the rest of my db tables e.g.
MSmerge_past_partition_mappings637451 Rows
MSmerge_current_partition_mappings350554 Rows
MSmerge_contents252368 Rows
The most amount of rows in any of my user defined tables is under 200,000
Rows. My question is - is there any way to fix these Replication tables
either my deleting the rows, running a cleanup script, etc. without affecting
the Subscribers?
Thanks for the help
http://www.mssqlserver.com/replication/purgemetadata.asp
This article will help you understand why the meger metadata tables can get
quite big.
You can run sp_mergemetadataretentioncleanup procedure to clean up some
metadata.
http://msdn2.microsoft.com/en-us/library/ms178557.aspx
Hope this helps.
"Cube" <ciaran@.nospam.insero-technologies.com> wrote in message
news:3F420705-1567-4257-9570-393795D005D8@.microsoft.com...
>I have a SQL 2005 Merge Replication setup with SQL Mobile Subscribers. The
> merge replication performance has been incredibly slow (a couple of hours
> in
> some cases). I looked at the size of some the Replication tables and their
> sizes are huge compared with the rest of my db tables e.g.
> MSmerge_past_partition_mappings 637451 Rows
> MSmerge_current_partition_mappings 350554 Rows
> MSmerge_contents 252368 Rows
> The most amount of rows in any of my user defined tables is under 200,000
> Rows. My question is - is there any way to fix these Replication tables
> either my deleting the rows, running a cleanup script, etc. without
> affecting
> the Subscribers?
> Thanks for the help
>

HELP: Learn replication in 25 mins

You won't be able to implement and fully support
replication in 25 mins. You might get it set up, but you
need to understand the internal infrastructure to a
reasonable level in order to make the correct design
choices and to be able to troubleshoot. I'd recommend:
(1) BOL is a good source of replication info but has no
screenshots.
(2) These links have some basic information:
http://www.mssqlcity.com/Articles/Replic/Replic.htm.
(3) The definitive guide for snapshot and transactional
is Hilary's book (see link below).
(4) There is a 3-day specialized Microsoft Course which
covers all the basics.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Hi,
Thanks to you both. You gave me enough info to blag my way through, just
need to implement it now.
Thanks again.
Rob