direct update

Doing transactional replication, set up with nosync initialization, it
seems to work great, but does not generate and does not use custom SPs
for each input/update/delete.
In the profiler I can see that, after I run a simple "update"
statement on the publisher, the same SQL gets run on the subscriber.
Which parameter of what call is it that determines whether I am using
this "direct update" business, and what are the implications, and
where (if anywhere!) is this discussed in BOL (or elsewhere), cuz I
can't find it!
Thanks.
Joshua Stern
On Mon, 22 Nov 2004 14:27:08 -0800, jxstern <jxstern@.nowhere.com>
wrote:
>Which parameter of what call is it that determines whether I am using
>this "direct update" business, and what are the implications, and
>where (if anywhere!) is this discussed in BOL (or elsewhere), cuz I
>can't find it!
Found it (in my own scripts, of course!)
exec sp_addarticle @.publication = N'myPUB', @.article = N'tbl_foo',
@.source_owner = N'dbo', @.source_object = N'tbl_foo',
@.destination_table = N'tbl_foo',
@.type = N'logbased', @.creation_script = null, @.description = null,
@.pre_creation_cmd = N'drop',
@.schema_option = 0x00000000000000F3, @.status = 0,
@.vertical_partition = N'false',
@.ins_cmd = N'SQL', @.del_cmd = N'SQL', @.upd_cmd = N'SQL',
@.filter = null, @.sync_object = null, @.auto_identity_range = N'false'
Those "@.ins_cmd" and such say "SQL", which echoes the SQL, rather than
use CALL, MCALL, or XCALL. See also BOL section, "Using Custom Stored
Procedures in Articles"
J.