Replication error - can not retrieve column information

does anyone have an idea of what generally could be wrong with a pull merge subscription when it errors out with the following:
sql server The merge process could not retrieve column information for table "tablename"
Also, could you tell me where I can get more details of errors (i.e. where the errorlog for replication is located
I found how to output the merge agent errors. Here is the output. Can anyone shed any light on this?
[5/15/2004 6:28:05 PM]BOSERVER-CSC3.vis-csc3: {call sp_MSgetversion }
Connecting to Publisher 'VIVA-SQLHQ.VIS'
Server: VIVA-SQLHQ
DBMS: Microsoft SQL Server
Version: 08.00.0760
user name: dbo
API conformance: 2
SQL conformance: 1
transaction capable: 2
read only: N
identifier quote char: "
non_nullable_columns: 1
owner usage: 31
max table name len: 128
max column name len: 128
need long data len: Y
max columns in table: 1024
max columns in index: 16
max char literal len: 524288
max statement len: 524288
max row size: 524288
[5/15/2004 6:28:05 PM]VIVA-SQLHQ.VIS: {call sp_MSgetversion }
Percent Complete: 5
Processing article 'viva_visit_qualified_statuses'
Percent Complete: 5
Processing article 'viva_inoffice_statuses'
Percent Complete: 5
Processing article 'Users'
The merge process could not retrieve column information for table 'dbo.viva_visit_qualified_statuses'.
The merge process could not retrieve column information for table 'dbo.viva_inoffice_statuses'.The merge process could not retrieve column information for table 'dbo.Users'.
The merge process could not retrieve column information for table 'dbo.Applicant Requirements'.
Percent Complete: 0
The merge process could not retrieve column information for table 'dbo.viva_visit_qualified_statuses'.
Percent Complete: 0
Category:NULL
Source: Merge Replication Provider
Number: -2147201016
Message: The merge process could not retrieve column information for table 'dbo.viva_visit_qualified_statuses'.
Percent Complete: 0
Category:COMMAND
Source: Failed Command
Number: 0
Message: {call sp_MSenumcolumns (?,?)}
Percent Complete: 0
Category:SQLSERVER
Source: BOSERVER-CSC3
Number: 2812
Message: Could not find stored procedure 'sp_sel_82D17F3FEACB41DE7A9684009ECD4868'.
Percent Complete: 0
Category:NULL
Source: Merge Replication Provider
Number: -2147201016
Message: The merge process could not retrieve column information for table 'dbo.viva_inoffice_statuses'.
Percent Complete: 0
Category:NULL
Source: Merge Replication Provider
Number: -2147201016
Message: The process was successfully stopped.
Disconnecting from Subscriber 'BOSERVER-CSC3'
Disconnecting from Publisher 'VIVA-SQLHQ'
Disconnecting from Subscriber 'BOSERVER-CSC3'
Disconnecting from Subscriber 'BOSERVER-CSC3'
Disconnecting from Subscriber 'BOSERVER-CSC3'
Disconnecting from Subscriber 'BOSERVER-CSC3'
Disconnecting from Publisher 'VIVA-SQLHQ'
Disconnecting from Publisher 'VIVA-SQLHQ'
Disconnecting from Publisher 'VIVA-SQLHQ'
Disconnecting from Publisher 'VIVA-SQLHQ'
Disconnecting from Publisher 'VIVA-SQLHQ'
Disconnecting from Distributor 'VIVA-SQLHQ'

Replication error

Hi

I am trying to replicate a database using the snapshot method. The publication worked fine, when the second server tried to pull the replication, it started, but then come up with the following error whilst creating the tables.

Insert Error: Column name or number of supplied values does not match table definition.

Any ideas?

cheers

SimonThe error usually occurs in transactional replication when someone accidentally changed the DDL in subscriber. You can reinitialize the subscription from the publication database and refresh your subscription.|||still no luck. Didn't help. Stil had the same error, any other ideas?

cheers

Replication Configuration Helper (Id buy it!)

Let's face it - setting up SQL 2005 merge pull replication using HTTPS between numerous SQL Server 2005 Express clients and one or more Publishers is an overly complicated exercise.

It should be easy. Why is it so hard?

In a nutshell: The connection chain and security chain is long and when there's a problem the error messages just don't point you to the answer - You have to search for it;re-read the doco; talk to gurus; use logging tools;re-read the error message 100 times; etc. etc.

It should be possible to create a 'Replication Configuration Helper' that steps -step by step - through both the connection chain (App - to SQL Express - to local network components - to the TCP/IP network - to the web server - to the publishers/distributers) and through the security chain (App - to SQL Express authentication - local agents including certificate errors - to ISS server authentication - to Distributer authentication -to Publisher authentication to Article authentication).

Let's face it - the steps occur in sequence and each step can be tested and the appropriate error message raised - TOGETHER WITH INSTRUCTIONS ON HOW TO RESOLVE! (I mean - what's use is an error message when you have to cut and past the error message into a browser and search for ages before you get the instructions on how to resolve the problem?)

So c'mon - someone volenteer to write a 'Replication Configuration Helper'

We are always looking to improve documentation, and we actually have an article in the works with regards to web sync with no release date yet, if you haven't noticed it's a very popular topic on this forum. We'll continue to update msdn, online version of books online, and kb articles on an ongoing basis and as needed. Thanks for your feedback.sql

replication between MS Access and SQL Server

Does anyone know the correct procedure to setup a pull relationship from MS Access to a SQL database and vice versa?http://vyaskn.tripod.com/repl_ans5.htm#sqljetsub for information.
And refer to books online

Replication as a job

For a pull snapshot replication: I want to run it as a job ie fully automated. Rite now I have start the 'Snapshot' under the publisher->Replication Monitor>Publishers>ServerName>Name.. and then manually start the Pull replication agent.

Is there a way to do this automatically ie in a job?You should be able to simply go to Agent Properties and set up a schedule for it.

Replication Architecture question - Pull subscriptions on a SQL cluster...

Greetings:

I am working on a replication setup using transactional replication using with pull subscriptions and a separate distributor. The pull subscriptions are located on a SQL cluster using the virtual SQL Server name as the subscriber; when the box fails over, we get an error of missing replication.dlls. Researching further, we found that replication only works on one node of the subscriber.

Any ideas on what we did wrong in the setup?

Thanks,

Lee Everest

www.texas2oo.com/sqlblog

can you check the c:\program files\Microsoft Sql Server\80\com folder to see if the dll's exist there? If not try to copy and register them on the failing node.|||

We could do that, but i'm afraid that after I try to install one, several (or dozens) of others might show up missing, meaning that we didn't install it properly in the first place. The specific error that we get is:

Cannot load the DLL replsetoriginator extended procedure, or one of the DLLs it references. Reason: 126(The specified module could not be found.). The step failed.

I have no idea which DLL this function is located but could probably find out.

|||This is a missing or corrupt dll. When I have encountered these in SQL FTS clusters I have had to copy the dll's to the failed not and reregister them.|||So you are saying that the setup is correct, and that if the box fails over replication should pick right back up?|||

A friend of mine responded, below. Apparently replication shouldn’t miss a beat if failover occurs:

Never had this issue before. We are running 4 node clusters (active/active/active/passive) here and we have never had that issue. I'm going to guess it goes back to the install of SQL. I would just copy any missing dll from one node to the other. It sounds like SQL is looking for them so I think you should be safe just to copy them over.

Any thoughts?

|||That depends on the programming mechanism. Sometimes they need to be registered and sometimes they don't. It these dll's contain com compoents they will be, if not a simple file copy will work.

Replication Architecture question - Pull subscriptions on a SQL cluster...

Greetings:

I am working on a replication setup using transactional replication using with pull subscriptions and a separate distributor. The pull subscriptions are located on a SQL cluster using the virtual SQL Server name as the subscriber; when the box fails over, we get an error of missing replication.dlls. Researching further, we found that replication only works on one node of the subscriber.

Any ideas on what we did wrong in the setup?

Thanks,

Lee Everest

www.texas2oo.com/sqlblog

can you check the c:\program files\Microsoft Sql Server\80\com folder to see if the dll's exist there? If not try to copy and register them on the failing node.|||

We could do that, but i'm afraid that after I try to install one, several (or dozens) of others might show up missing, meaning that we didn't install it properly in the first place. The specific error that we get is:

Cannot load the DLL replsetoriginator extended procedure, or one of the DLLs it references. Reason: 126(The specified module could not be found.). The step failed.

I have no idea which DLL this function is located but could probably find out.

|||This is a missing or corrupt dll. When I have encountered these in SQL FTS clusters I have had to copy the dll's to the failed not and reregister them.|||So you are saying that the setup is correct, and that if the box fails over replication should pick right back up?|||

A friend of mine responded, below. Apparently replication shouldn’t miss a beat if failover occurs:

Never had this issue before. We are running 4 node clusters (active/active/active/passive) here and we have never had that issue. I'm going to guess it goes back to the install of SQL. I would just copy any missing dll from one node to the other. It sounds like SQL is looking for them so I think you should be safe just to copy them over.

Any thoughts?

|||That depends on the programming mechanism. Sometimes they need to be registered and sometimes they don't. It these dll's contain com compoents they will be, if not a simple file copy will work.

Replication and security..is it really this UNSECURE!

Hi Guys
I need to create an anonymous pull subscription over the Internet.
I've got everything working but I don't want my subscribers to be able
to connect to the publisher/distributor via Enterprise Manager or
ISQLW or anything else for that matter!! Basically they should only
be able to talk to the Publishing SQL Server through replication
methods. How is this achieved?
I'm currently using SQL Security because I don't want an anonymous
subscriber to impersonate my publishers sqlserver agent account, the
agent on the publisher is used for other scheduled tasks that needs
Domain Admin privileges, am I missing something here!!'
Currently I've got it secure-ish. I've used a specific sql account
and given it access in the PAL and removed the guest account from
other DBs, however you cannot remove the guest account from Master or
Msdb and said account must also be a member of the db_owner role. The
most they can do is issue select statements against tables but I think
that is even too much, for instance they can query sysservers which
would allow them to see other subscribers that we do business with.
Even if I use a secure VPN between publisher and subscriber what's to
stop an inquistive subscriber, using the SQL account that I've told
them to use for their subscription, connecting using EM or ISQLW
through the VPN? Surely there must be a way to give ONLY replication
access but nothing else?
Please help!!What type of Replication are you implementing? Snapshot/Transactional or
Merge ?
If they have the data on the Subscriber, there would really be no need to
connect to the Publisher. So, if the users are connecting to the
Subscribing database, that's all they should need.
Are you attempting to restrict access to the Subscribed database?
There isn't a way to restrict access FROM a particular application. So, if
you allow the user to connect to the Server and grant them access to the
database, then they have access from *any* odbc or oledb application.
There isn't a way to restrict this.
Replication works using the accounts designated with the Agents. It
doesn't rely on what permissions the users have.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

Replication and security..is it really this UNSECURE!

Hi Guys
I need to create an anonymous pull subscription over the Internet.
I've got everything working but I don't want my subscribers to be able
to connect to the publisher/distributor via Enterprise Manager or
ISQLW or anything else for that matter!! Basically they should only
be able to talk to the Publishing SQL Server through replication
methods. How is this achieved?
I'm currently using SQL Security because I don't want an anonymous
subscriber to impersonate my publishers sqlserver agent account, the
agent on the publisher is used for other scheduled tasks that needs
Domain Admin privileges, am I missing something here!!?
Currently I've got it secure-ish. I've used a specific sql account
and given it access in the PAL and removed the guest account from
other DBs, however you cannot remove the guest account from Master or
Msdb and said account must also be a member of the db_owner role. The
most they can do is issue select statements against tables but I think
that is even too much, for instance they can query sysservers which
would allow them to see other subscribers that we do business with.
Even if I use a secure VPN between publisher and subscriber what's to
stop an inquistive subscriber, using the SQL account that I've told
them to use for their subscription, connecting using EM or ISQLW
through the VPN? Surely there must be a way to give ONLY replication
access but nothing else?
Please help!!
The problem is not with replication and security, but rather a larger one
with SQL Server security in general. Anytime you create an account on that
server, and give that account rights to only one user database, this account
can query system tables on the master database.
I suggest you post this question to the microsoft.public.sqlserver.security
newsgroup.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"greedo" <d8rrylf@.msn.com> wrote in message
news:f0badc7a.0408170010.47baef00@.posting.google.c om...
> Hi Guys
> I need to create an anonymous pull subscription over the Internet.
> I've got everything working but I don't want my subscribers to be able
> to connect to the publisher/distributor via Enterprise Manager or
> ISQLW or anything else for that matter!! Basically they should only
> be able to talk to the Publishing SQL Server through replication
> methods. How is this achieved?
> I'm currently using SQL Security because I don't want an anonymous
> subscriber to impersonate my publishers sqlserver agent account, the
> agent on the publisher is used for other scheduled tasks that needs
> Domain Admin privileges, am I missing something here!!?
> Currently I've got it secure-ish. I've used a specific sql account
> and given it access in the PAL and removed the guest account from
> other DBs, however you cannot remove the guest account from Master or
> Msdb and said account must also be a member of the db_owner role. The
> most they can do is issue select statements against tables but I think
> that is even too much, for instance they can query sysservers which
> would allow them to see other subscribers that we do business with.
> Even if I use a secure VPN between publisher and subscriber what's to
> stop an inquistive subscriber, using the SQL account that I've told
> them to use for their subscription, connecting using EM or ISQLW
> through the VPN? Surely there must be a way to give ONLY replication
> access but nothing else?
> Please help!!

Replication and distribution: Agents

Hi all replication experts...

I have created transactional replication on my servers (production server and backup server) and created pull subscription at the backup server. On my production server that also is a distributor and publisher there exist two agents, Snapshot agent and Log reader in the Publishers folder under replication Monitor.

There are also another agent with the backup server name and database name: BackServ:DBName having the type Pull and 'No replicated transactions are available' as Last Action. My question is: What is this? Must it be there?

Grateful for answers

Best,
/M

Its hard to say exactly what this is, but it appears to be your distribution agent. You appear to have a pull agent configured on your subscriber.

It is essential for your transactional replication topology. Do not remove it.

Hilary

|||OK, thanks :)

Replication and Deleting Rows

Hello,
I have a large table with over 20 million rows.
It is replicated accross a 4 subscribers using Pull subscription. One of the
subscribers is also a Distributor.
We are running some processed to "clean up" the data in this table by
issuing a lot of DELETE commands (using Primary Key as the where clause)
against the large table. The DELETE commands are enclosed in BEGIN TRAN -
COMIT TRAN batches of 20 each.
The deletion works extremely fast on the Publisher.
However, it takes very very long time to apply the very same commands on all
of the subscribers. The subscribers also have the PRIMARY KEY index that is
on the Publisher.
We need to delete a few million rows from the large table using this
technique. However, it makes the Subscribers very slow and unresponsive.
Any suggestions?
Thanks,
ArsenConsider doing this in even smaller batches. If that is not possible, and
transactional consistency is not really of importance, then you could use a
parameter called MaxCmdsInTran for logreader (introduced in SQL Server 2000
SP1 I believe). This breaks huge transactions into smaller chunks of
specified size, while storing the commands in distribution database.
There is another approach, that I would recommend. Consider using 'stored
procedure execution' replication. With this method, you keep a copy of the
archiving stored procedure on all subscribers. When you run this procedure
on the publisher, the distribution agent will call this sp on all
subscribers, instead of sending millions of DELETEs over the network. See
SQL Server Books Online for more information on this.
--
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Arsen V." <arsen@.community.nospam> wrote in message
news:%23hpi4tKoEHA.2612@.TK2MSFTNGP15.phx.gbl...
> Hello,
> I have a large table with over 20 million rows.
> It is replicated accross a 4 subscribers using Pull subscription. One of
the
> subscribers is also a Distributor.
> We are running some processed to "clean up" the data in this table by
> issuing a lot of DELETE commands (using Primary Key as the where clause)
> against the large table. The DELETE commands are enclosed in BEGIN TRAN -
> COMIT TRAN batches of 20 each.
> The deletion works extremely fast on the Publisher.
> However, it takes very very long time to apply the very same commands on
all
> of the subscribers. The subscribers also have the PRIMARY KEY index that
is
> on the Publisher.
> We need to delete a few million rows from the large table using this
> technique. However, it makes the Subscribers very slow and unresponsive.
> Any suggestions?
> Thanks,
> Arsen
>

Replication and Deleting Rows

Hello,
I have a large table with over 20 million rows.
It is replicated accross a 4 subscribers using Pull subscription. One of the
subscribers is also a Distributor.
We are running some processed to "clean up" the data in this table by
issuing a lot of DELETE commands (using Primary Key as the where clause)
against the large table. The DELETE commands are enclosed in BEGIN TRAN -
COMIT TRAN batches of 20 each.
The deletion works extremely fast on the Publisher.
However, it takes very very long time to apply the very same commands on all
of the subscribers. The subscribers also have the PRIMARY KEY index that is
on the Publisher.
We need to delete a few million rows from the large table using this
technique. However, it makes the Subscribers very slow and unresponsive.
Any suggestions?
Thanks,
Arsen
Consider doing this in even smaller batches. If that is not possible, and
transactional consistency is not really of importance, then you could use a
parameter called MaxCmdsInTran for logreader (introduced in SQL Server 2000
SP1 I believe). This breaks huge transactions into smaller chunks of
specified size, while storing the commands in distribution database.
There is another approach, that I would recommend. Consider using 'stored
procedure execution' replication. With this method, you keep a copy of the
archiving stored procedure on all subscribers. When you run this procedure
on the publisher, the distribution agent will call this sp on all
subscribers, instead of sending millions of DELETEs over the network. See
SQL Server Books Online for more information on this.
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Arsen V." <arsen@.community.nospam> wrote in message
news:%23hpi4tKoEHA.2612@.TK2MSFTNGP15.phx.gbl...
> Hello,
> I have a large table with over 20 million rows.
> It is replicated accross a 4 subscribers using Pull subscription. One of
the
> subscribers is also a Distributor.
> We are running some processed to "clean up" the data in this table by
> issuing a lot of DELETE commands (using Primary Key as the where clause)
> against the large table. The DELETE commands are enclosed in BEGIN TRAN -
> COMIT TRAN batches of 20 each.
> The deletion works extremely fast on the Publisher.
> However, it takes very very long time to apply the very same commands on
all
> of the subscribers. The subscribers also have the PRIMARY KEY index that
is
> on the Publisher.
> We need to delete a few million rows from the large table using this
> technique. However, it makes the Subscribers very slow and unresponsive.
> Any suggestions?
> Thanks,
> Arsen
>

Replication (pulling a subscription)

I am trying to pull subscription for a database but I always get the error message ...
Error 15004: Name cannot be null
What exactly have I done wrong
Plaese help
Thanks
Nneka EchebeLets' go thru the process again. I just tried to replicate with northwind. The problem I came up with is nameing convention. It would not accept the local name for the server. It has to have a proper registration name. I also found out that you must replication from the server or sa level. Meaning that remote loggins must have the highest level of access.

Replication - sp_MSget_subscription_guid impossible

We currently have a pull transactional subscription running from a remote 'PublicationServer' in another country to our local server.

After restarting our fire wall we get the following error message:
"The process could not execute '{call sp_MSget_subscription_guid(16)}' on 'PublicationServer'."

This message is followed by another error message: "Another distribution agent for the subscription(s) is running.", although nothing was changed to the configuration and no SQL processes were started or restarted.

When we restart the distribution job manually it runs as if nothing happened.

Does anyone know what exactly caused the failure, and how to prevent it ?

PhilipQuit restarting your firewall ?

I really don't have a good answer for this question. Sometimes after an unexpected failure, the simplest answer is just to manually restart what won't start automagically.

-PatP

Replicating Matched MS SQL HR Data to Active Directory's Metadirectory fields

I've managed to do the add linkedserver stuff and pull up of some active
directory information.
I even matched up some data but could never insert anything into the AD Meta
fields.
I used this article,
http://msluder.dk/Resources/ADSI%20S...%20HTML/dq.htm ,which never
promised insert capabilities.
But if this is all it can do is give the ability to run some obscure reports
then it's hardly useful.
What I would like to do is create a view that would dynamiclly update the AD
Meta data from the Human Resources Database using the CN and / or
Primary-Email Address as the linking field.
That way when people change office numbers or as new employees start that
Meta information would be updated once it was entered or altered by HR.
It seems this would be possible via some kind of replication or event based
update through the SQL Server.
Any one have some ideas on this?
-Ethan
Ethan,
have a look at the Microsoft Script Repository
(http://www.microsoft.com/downloads/d...n&FamilyID=B4C
B2678-DAFB-4E30-B2DA-B8814FE2DA5A) there are scripts there to update AD.
HTH,
Paul Ibison
|||Have a look at the Replication Distributor Interface Reference in BOL.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html