Hi Steve

Yeah, we only do use a few hundred but the data is scattered all over.
I think, for safety's sake, we'd need to set up triggers on...

Hi Sue

Apologies, badly written response to your last post.

What I meant to say was......
Under normal circumstances, I would take the defaults for replication.  In this...

I've never tried log shipping before so that will be a bit of learning curve (not too steep from the research I've done).
With replication, I tend to take the...

Thanks Sue

We'll be testing this on a couple of small(ish) test databases to start with (39GB and 23GB).
Not a lot is used on these (and if it...

At the risk of clutching at straws, how about:-
1) Back up databases on A
2) Restore database on B
3) Set up replication from B to C & D

Hi Sue

We could but we wouldn't be able to add any new indexes (which is the main aim of this as well as getting local copies of the...

Thanks Perry.
Looks like we're gong to have to have a rethink of the plan,

Thanks sue

Looks like a small rethink in the plan is needed.
We haven't done anything as yet as it's still in the planning stage.
I suppose we could...

Thanks sue

As the number of cubes grow (especially tabular ones), I wanted to somehow write a loop to process them all together rather than having several tasks in...

Has anyone managed to come up with a way to do this?

That was just about it.
I tried to process the model after restarting  Visual Studio but it still didn't work.
Looks like it was either forgotten password or the saved...

No problem, and thanks to one and all once again.

To be honest, it wasn't very scientific.
We split them into 300 column "lumps".
We've quite of few of these stupidly-wide tables to load but didn't notice at the time.

We've decided to split the table into sections (with _1, _2, etc. where necessary).
We kept the first few columns static in each table so we can join them together...