Merge Agent Error: invalid column 'rowguid'

I get this error when I Push New subscription and indicate NO, to initialize
schema and data.
the wizard dialog is: Initial Subscription, and I am choosing: No,
subscriber already has schema and data
Does the subscriber have an identical table ther already (including the guid
column)?
Regards,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||No. I just have four tables in my publication and checked for that first.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23W53vgb%23EHA.2608@.TK2MSFTNGP10.phx.gbl...
> Does the subscriber have an identical table ther already (including the
> guid
> column)?
> Regards,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Robert,
the table must already be there in a nosync initialization, in identical
format to the publisher one.
If you are saying it isn't there, then you'll need to use backup/restore or
DTS or some other means to transfer it.
Rgds,
Paul Ibison
"Robert A. DiFrancesco" <bob.difrancesco@.comcash.com> wrote in message
news:OoAgSmb%23EHA.2032@.tk2msftngp13.phx.gbl...
> No. I just have four tables in my publication and checked for that first.
>
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:%23W53vgb%23EHA.2608@.TK2MSFTNGP10.phx.gbl...
>
|||Thank you Paul. I feel special today with all your attention.
I meant the column rowguid; I checked that it was not present as I assume
the PushNewSubscription process will create the column in the table at the
subscriber.
What I really am trying to accomplish, and forgive me, is how do I "turn on
replication" at the publisher-machine when my subscriber machine is already
in a working-production environment?
My thinking is that I start with a blank database at the publisher, schema
matching the subscriber, and enable publishing and push a new subscription
but NOT intializing schema and data. Because I'm guessing the blank
database at the publisher will destroy all records at the live subscriber,
making it blank also. Am I correct and what is the solution?
Thank you very, very much.
Bob
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23dAW%23ub%23EHA.2804@.TK2MSFTNGP15.phx.gbl.. .
> Robert,
> the table must already be there in a nosync initialization, in identical
> format to the publisher one.
> If you are saying it isn't there, then you'll need to use backup/restore
> or
> DTS or some other means to transfer it.
> Rgds,
> Paul Ibison
> "Robert A. DiFrancesco" <bob.difrancesco@.comcash.com> wrote in message
> news:OoAgSmb%23EHA.2032@.tk2msftngp13.phx.gbl...
>
|||Robert,
please keep the questions coming - this is my great
hobby
The initialization process can do one of two things:
(a) if you choose a synch initialization, then the
complete table will be BCPd out into the repldata share.
In that share there'll be several textfiles - for
creating the schema, the indexes, one containing data,
but the initial text file contains simply a 'drop table'
statement. That means that it really doesn't matter what
is on the subscriber - there can be a table of the same
name or not. if there is, it'll be deleted anyway.
(b) you select to do a nosync initialization. In this
case, the exact ssame table (inc guid) must exist on the
subscriber. The initialization process will create
metadata tables on the subscriber, but it won't touch the
replicated table at all.
There are further variations if we consider other options
for @.pre_creation_cmd, where you can select to leave the
table there if it already exists and such like, but these
are for specialist scenarios.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

MemToLeave and Thirdy Pary DLLs

Hi
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.com
Hi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
..dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defau...v_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com

MemToLeave and Thirdy Pary DLLs

Hi
I've been running into problems with a server that indicate that space in the
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker threads
and using the default -g will add another 256M, bringing the default to 384M.
BOL is woolly on the subject, as normal.
Thanks
Mark
--
Message posted via http://www.sqlmonster.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsqldev/html/sqldev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via SQLMonster.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.sqlmonster.comsql

MemToLeave and Thirdy Pary DLLs

Hi
I've been running into problems with a server that indicate that space in th
e
MemToLeave area is exhausted. The messages in the error log are along the
lines of 'Failed to reserve contigous memory', 'Clearing procedure cache to
free contigous memory' et cetera.
We do have a third party DLL in use and I've seen in a previous post a
recommendation to move third party DLLs out of the production server's
address space. The question is how to do this? My NT administrators don't
know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I can
do once a problem has occurred, but is there a way of ensuring the DLL is
always out of the server's address space?
If I unload the DLL what is to stop it meing reloaded, as it is used by
database monitoring software that runs every two minutes?
I'm also a little confused by the -g startup setting.
One post I've seen says to set it to 384 to increase the space available to
the MEmToLeave. Another post states that you need 128M for the worker thread
s
and using the default -g will add another 256M, bringing the default to 384M
.
BOL is woolly on the subject, as normal.
Thanks
Mark
Message posted via http://www.droptable.comHi Mark
Some .dll's are designed to be run either in-process or ex-process & some
are simply designed to run in-process, so some can be forced to run
ex-process & some can't.
The type that typically *can* be run ex-process from SQL Server are COM type
.dlls, typically developed in VB6.0 (but can also be developed in Delphi,
C++ or J++0). you know you're dealing with one of these if the calling code
uses the sp_OACreate syntax. To make these guys run ex-process, you
configure them to run within COM+ or (or MTS on older WinNT) context, which
requires registering them in COM+.
The type that typcially *cannot* be run ex-process from SQL Server are
Extended Stored procedures, which are typically written in C and simply
aren't designed to be run ex-process. So if you're talking about a .dll
which is registered as an Extended Stored Proc, you probably won't be able
to make it run ex-process.
The post about the -g switch is correct. SQL Server's allocation of memory
during startup is best documented in Ken Henderson's Internals Guru's Guide
book. He's also written articles on SQL Memory Management, one of which is
here:
http://msdn.microsoft.com/data/defa...ev_01262004.asp
But I dono't think this one specifically covers the -g switch in the detail
you're after. Try to get hold of the book, as it'd definitely covered in
detail in its Memory chapter.
HTH
Regards,
Greg Linwood
SQL Server MVP
"mpenfold via droptable.com" <u16092@.uwe> wrote in message
news:58090a9e28698@.uwe...
> Hi
> I've been running into problems with a server that indicate that space in
> the
> MemToLeave area is exhausted. The messages in the error log are along the
> lines of 'Failed to reserve contigous memory', 'Clearing procedure cache
> to
> free contigous memory' et cetera.
> We do have a third party DLL in use and I've seen in a previous post a
> recommendation to move third party DLLs out of the production server's
> address space. The question is how to do this? My NT administrators don't
> know. BOL tells me how to unload the DLL (DBCC dllname (FREE)), which I
> can
> do once a problem has occurred, but is there a way of ensuring the DLL is
> always out of the server's address space?
> If I unload the DLL what is to stop it meing reloaded, as it is used by
> database monitoring software that runs every two minutes?
> I'm also a little confused by the -g startup setting.
> One post I've seen says to set it to 384 to increase the space available
> to
> the MEmToLeave. Another post states that you need 128M for the worker
> threads
> and using the default -g will add another 256M, bringing the default to
> 384M.
> BOL is woolly on the subject, as normal.
> Thanks
> Mark
> --
> Message posted via http://www.droptable.com