Prev: SQL database not accessible during transactional replication
Next: skiperrors
From: Ben Thul on 3 Mar 2010 22:17
That's my fault...I saw the same behavior. When I did it with @type =
'indexed view schema only' did create the indexed view.
--
Ben

On Mar 3, 6:32 pm, jk <j...(a)discussions.microsoft.com> wrote:
> Thanks, Ben. Your test worked, except as I expected, per the @type = 'indexed
> view logbased' in your script, it created a TABLE on the subscriber instead
> of the VIEW I wanted.
>
> Jan.

From: jk on 4 Mar 2010 11:37
You are right. It does seem to work. I did it on the same database (and
server), and it worked, while the other articles dont. It has to be some sort
of glitch because all the settings are the same. Will have to experiment some
more as this test shows that it should work.

"Ben Thul" wrote:

> That's my fault...I saw the same behavior. When I did it with @type =
> 'indexed view schema only' did create the indexed view.
> --
> Ben
>
> On Mar 3, 6:32 pm, jk <j...(a)discussions.microsoft.com> wrote:
> > Thanks, Ben. Your test worked, except as I expected, per the @type = 'indexed
> > view logbased' in your script, it created a TABLE on the subscriber instead
> > of the VIEW I wanted.
> >
> > Jan.
>
> .
>
From: Ben Thul on 4 Mar 2010 11:52
One thing that I thought of...try creating the view manually at the
subscriber. Maybe there's some weird condition that prevents the
indexed view from being created there. If that's the case, it could
be detected by replication and lead to the situation you're seeing.
Just a thought...
--
Ben

On Mar 4, 10:37 am, jk <j...(a)discussions.microsoft.com> wrote:
> You are right. It does seem to work. I did it on the same database (and
> server), and it worked, while the other articles dont. It has to be some sort
> of glitch because all the settings are the same. Will have to experiment some
> more as this test shows that it should work.

First  |  Prev  | 
Pages: 1 2
Prev: SQL database not accessible during transactional replication
Next: skiperrors