Hi,
I saw an article on www.replicationanswers.com, about Altering a column on a
Replicated Table (from Paul Ibison):
exec sp_dropsubscription @.publication = 'tTestFNames'
, @.article = 'tEmployees'
, @.subscriber = 'RSCOMPUTER'
, @.destination_db = 'testrep'
exec sp_droparticle @.publication = 'tTestFNames'
, @.article = 'tEmployees'
alter table tEmployees alter column Forename varchar(100) null
exec sp_addarticle @.publication = 'tTestFNames'
, @.article = 'tEmployees'
, @.source_table = 'tEmployees'
exec sp_addsubscription @.publication = 'tTestFNames'
, @.article = 'tEmployees'
, @.subscriber = 'RSCOMPUTER'
, @.destination_db = 'testrep'
I DID THE SAME FOR NO-SYNC INITITIALIZATION, BUT THE STRUCTURE OF THE FIELD
IN SUBCRIBER IS THE SAME, THIS CHANGE IS NOT BEING PUBLISHED IN THE
SUBSCRIBER.
CAN SOMEBODY HELP ME TO SOLVE THIS ISSUE FOR NO-SYNC INITIALIZATION, HOW THE
SCRIPT SHOULD LOOK LIKE OR WHAT DO IA HEVE TO DO?
Thanks,
BaniSQL.
Isn't @.sync_type = automatic the default one, I mean if you don't specify it
will take the automatic one. I tried like that, but than some foreign keys
referencing that table were firing.
I'm trying to alter a column, is not another way of doing it beside this one
droping the whole article and replicating again. This soltion is fine for me
as logn is it will work, but the problem is that the foeign keys are firing
and some related records to other related tables can't find.
Please help.
Thnx,
BaniSQL
"Paul Ibison" wrote:
> It all depends on whether you want to do an automatic one or another nosync
> one. The easiest way is to drop the article and subscription then readd it
> as @.sync_type = automatic.
> Cheers,
> Paul Ibison
>
>
Showing posts with label exec. Show all posts
Showing posts with label exec. Show all posts
Sunday, March 25, 2012
Sunday, February 12, 2012
All procedure in a stored procedure not being exec
I have a stored procedure that is called but it seems that not all the
Stored procedures are run. If I execute it the second time then they seem to
run after that.
Am I missing something, Like added a wait to finish clause?
Stephen K. Miyasato
MDsync
CREATE PROCEDURE FLG_UpdateFlags
/*Stored Procedure to update All the Flags*/
@.PatNo int
AS
--Put optional Flag procedures here
--
--Procedure to delete FOBT if Colonoscopy duedate is > todays or to be done
Exec FLG_FOBT @.PatNo
--procedure to delete old flags Set LastDate to Visit date in Vistal Signs
Exec FLG_OfficeVisit @.PatNo
-- Update Labs based on sort and ProtScr
Exec FLG_LabDateCholesterol @.PatNoStephen K. Miyasato (miyasat@.flex.com) writes:
> I have a stored procedure that is called but it seems that not all the
> Stored procedures are run. If I execute it the second time then they
> seem to run after that.
How do you conclude this? From where do you run the procedure? Have you
traced the procedure in Profiler to see what is going on?
The only thing I can guess on is that first time you run the procedure,
there is an error that causes the batch to be aborted, but this does
for some reason not happen when you re-run the procedure.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Stored procedures are run. If I execute it the second time then they seem to
run after that.
Am I missing something, Like added a wait to finish clause?
Stephen K. Miyasato
MDsync
CREATE PROCEDURE FLG_UpdateFlags
/*Stored Procedure to update All the Flags*/
@.PatNo int
AS
--Put optional Flag procedures here
--
--Procedure to delete FOBT if Colonoscopy duedate is > todays or to be done
Exec FLG_FOBT @.PatNo
--procedure to delete old flags Set LastDate to Visit date in Vistal Signs
Exec FLG_OfficeVisit @.PatNo
-- Update Labs based on sort and ProtScr
Exec FLG_LabDateCholesterol @.PatNoStephen K. Miyasato (miyasat@.flex.com) writes:
> I have a stored procedure that is called but it seems that not all the
> Stored procedures are run. If I execute it the second time then they
> seem to run after that.
How do you conclude this? From where do you run the procedure? Have you
traced the procedure in Profiler to see what is going on?
The only thing I can guess on is that first time you run the procedure,
there is an error that causes the batch to be aborted, but this does
for some reason not happen when you re-run the procedure.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Subscribe to:
Posts (Atom)