ksDevGuy wrote:
> Ahh, yes - not the problem. Since we are trying to only replicate the data
> tables, my concern was if I restore a full database at the client from a
> backup (that has the SP's, views, triggers, tables, etc.) will the snapshot
> of the tables-only replication blow out the existing DB or will it nicely
> update the table portion only leaving the rest?
>
> If it played nice, then we're golden!
>
> Thanks again for taking the time, it's a big help.
>
> Tony
>
> "JE" wrote:
>
>> I take it you don't want to pull the whole snapshot over the wire at the
>> client? You can always take the snapshot with you and tell the
>> subscription to find the snapshot in an alternate location.
>>
>> ksDevGuy wrote:
>>> Thank you, this is the course we are following I think. However, an
>>> incredibly simple item has brought us to a halt ---- how do you merge
>>> replicate & bypass the snapshot?!
>>>
>>> No matter what I try, the client wants to pull a snapshot before it will
>>> replicate the tables. I am trying to do a restore of the main database before
>>> replication at the client first. Then subscribe the client to the main
>>> server, and do a pull.
>>>
>>> Thoughts, suggestions?
>>>
>>> Thanks to everyone for the helpful replies BTW.
>>>
>>> Tony
>>>
>>> "JE" wrote:
>>>
>>>> The error points to a script failing because some objects referenced by
>>>> the script do not exist. For example, you cannot create a trigger on a
>>>> table that does not exist, or include a column that does not exist in a
>>>> view. There are many reasons for this happening, and you can start by
>>>> looking at the hd2_genetic_200.sch script to see what went wrong.
>>>>
>>>> To avoid many of these schema problems it is best to create the target
>>>> database and schema manually before you create the subscription. Create
>>>> one big script to create all objects in the correct order and make sure
>>>> it runs without errors. Also only include tables in the publication -
>>>> don't replicate views, procs, etc. That way your snapshot schema is much
>>>> less complex.
>>>>
>>>>
>>>> ksDevGuy wrote:
>>>>> SQL 2005 Express SP1 pulling a merge replication from the command line using
>>>>> replmerg.exe from a SQL 2005 Std SP1 database, works great on our simple test
>>>>> databases.
>>>>>
>>>>> However, with the bigger more complex application we need to replicate (uses
>>>>> SP's, views, tables, etc.) we get the following output from the command line
>>>>> merge:
>>>>>
>>>>> 2007-01-30 22:03:01.011 The schema script 'hd2_genetic_200.sch' could not be
>>>>> propagated to the subscriber.
>>>>> 2007-01-30 22:03:01.201 Category:NULL
>>>>> Source: Merge Replication Provider
>>>>> Number: -2147201001
>>>>> Message: The schema script 'hd2_genetic_200.sch' could not be propagated to
>>>>> the subscriber.
>>>>> 2007-01-30 22:03:01.211 Category:AGENT
>>>>> Source: nextop
>>>>> Number: 20164
>>>>> Message: Unable to replicate a view or function because the referenced
>>>>> objects or columns are not present on the Subscriber.
>>>>> 2007-01-30 22:03:01.211 Category:NULL
>>>>> Source: Microsoft SQL Native Client
>>>>> Number: 208
>>>>> Message: Invalid object name 'hd_genetic'.
>>>>>
>>>>> Am against the wall on this one. Any help would be greatly appreciated?
>>>>> Anyone? MS Tech?
>>>>>
>>>>> Thanks all,
>>>>> ksDevGuy