Thanks for that.
I'll take a look at the XML and see what we can do.

At that stage, yes.
Personally, I don't think we'll ever use this particular document  for reporting purposes but we've told to load it "just in case".
We do need to...

Me neither, but the load process is uniform.
I'll fully agree the document is cr@p.

Thanks all

Unfortunately, I can't make that decision arbitrarily.

I'll have a chat with my boss and see what he says.
I think we'll have to go that...

I'd spotted that (see my previous reply) but I'm not sure if that would tip me over the edge (figuratively speaking).

We could normalise the data but it would...

It's possible, the extra column is  datetime column (which would add 8 bytes).
The primary key column add up to a maximum of 67 bytes.  That's these columns:-
[pkDocumentID] [VARCHAR](30)

Apologies, yes.  We take the staging table data (i.e. the new/updated data) and do a blanket insert of that record into the actual table from the staging table assuming it...

I'm aware you suggested running it against a single table, but this is on our development server (with backups) and we have a lot of tables with this issue.

We're looking to move to TFS for database version control in the very near future.
I just wanted a system that we could set up in the meantime.

Looks...

Thanks Scott - I'll give that a go and see what happens when we next load the (currently) problem tables.

Unfortunately, that's how the document is designed on the system.
We've asked for repeating sections instead of being specifically number 1 to nnn and being a very wide table.

Hi Steve

I know about TFS (although I'm fair from an expert).
I'm not clear on how we could track indexes and have them in a convenient place to...