<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://petersap.nl/SybaseWiki/index.php?action=history&amp;feed=atom&amp;title=Error_Number_28049</id>
		<title>Error Number 28049 - Revision history</title>
		<link rel="self" type="application/atom+xml" href="http://petersap.nl/SybaseWiki/index.php?action=history&amp;feed=atom&amp;title=Error_Number_28049"/>
		<link rel="alternate" type="text/html" href="http://petersap.nl/SybaseWiki/index.php?title=Error_Number_28049&amp;action=history"/>
		<updated>2026-04-04T20:48:24Z</updated>
		<subtitle>Revision history for this page on the wiki</subtitle>
		<generator>MediaWiki 1.24.2</generator>

	<entry>
		<id>http://petersap.nl/SybaseWiki/index.php?title=Error_Number_28049&amp;diff=1832&amp;oldid=prev</id>
		<title>Psap at 14:22, 20 January 2009</title>
		<link rel="alternate" type="text/html" href="http://petersap.nl/SybaseWiki/index.php?title=Error_Number_28049&amp;diff=1832&amp;oldid=prev"/>
				<updated>2009-01-20T14:22:05Z</updated>
		
		<summary type="html">&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;In some exceptional cases, error number 28049 (Cannot find subscription &amp;lt;hex-number&amp;gt; in system tables) is raised in the errorlog of replication server. This can be caused when a subscription is dropped from the replication server by updating the RSSD database manualy, rather than using &amp;quot;drop subscription&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
==Sample error==&lt;br /&gt;
Here is a sample of the error, taken from the Replication Server errorlog:&lt;br /&gt;
&lt;br /&gt;
 E. 2009/01/17 14:38:18. ERROR #28049 DSI(112 SPC_AM_SUM.summitdb) - sub_rsts.c(519)&lt;br /&gt;
 	Cannot find subscription &amp;lt;0x0100006580000afc&amp;gt; in system tables&lt;br /&gt;
&lt;br /&gt;
==Known solutions==&lt;br /&gt;
There are two known resolutions for this issue.&lt;br /&gt;
&lt;br /&gt;
===drop connection===&lt;br /&gt;
The easy way is to drop the connection as mentioned in the errorlog, in this case the connection to SPC_AM_SUM.summitdb. This may not always be possible. After the connection has been dropped, re-create it using the create connection command.&lt;br /&gt;
&lt;br /&gt;
===sysadmin sqm_purge_queue===&lt;br /&gt;
To clear this final reference to the subscription, you must run &amp;quot;sysadmin sqm_purge_queue&amp;quot; on the outbound queue associated with this message. For example, assuming the message is associated with outbound queue &amp;quot;112:0&amp;quot;, proceed as follows:&lt;br /&gt;
* Suspend all routes into this repserver that could possibly be inserting changes intended for the outbound queue in question.&lt;br /&gt;
* Suspend all LTMs/RATs into this repserver that could possibly be inserting changes intended for the outbound queue in question.&lt;br /&gt;
* Use &amp;quot;admin who,sqm&amp;quot; to confirm that the outbound queue in question is infact empty. IE, Confirm that the value reported for &amp;quot;First Seg.Block&amp;quot; is equal to the value reported for &amp;quot;Last Seg.Block&amp;quot;.&lt;br /&gt;
* Place Repserver in &amp;quot;Hibernate&amp;quot; mode&lt;br /&gt;
&lt;br /&gt;
 sysadmin hibernate_on&lt;br /&gt;
&lt;br /&gt;
* Issue the command&lt;br /&gt;
&lt;br /&gt;
 sysadmin sqm_purge_queue, 112, 0&lt;br /&gt;
&lt;br /&gt;
* Return Repserver to normal processing mode:&lt;br /&gt;
&lt;br /&gt;
 sysadmin hibernate_off&lt;br /&gt;
&lt;br /&gt;
* Resume Routes into this repserver.&lt;br /&gt;
* Restart all LTMs/RATs into this repserver.&lt;br /&gt;
&lt;br /&gt;
[[Category:RepServer]]&lt;/div&gt;</summary>
		<author><name>Psap</name></author>	</entry>

	</feed>