Post the plan in text form....they usually are fairly readable.

regarding the data....can you drum up a mini-set approx10 rows and line it up with a matching expected result.  4m rows...

"Here is the design of the table.

CREATE TABLE [dbo].[PolygonTileIndex] (

 [TIX] [int] NULL ,

 [TIY] [int] NULL ,

 [MSLINK] [int] NULL

) ON [PRIMARY]

GO"

and what indices are in place?????

with regard to the sample...

4 things.

1.  the drop and create may be causing the SP to re-compile.  try to move this outside the SP.

2.  your dropping/creating of 1 table....has implications for running 2 people...

Aha...the classic mistake...you know a problem is possible to occur, but rather than taking steps to minimise the fallout, you penalise the inevitable mistake...."It's like I tell my kids: it's...

When you say database file....do you mean the "data" or the "log" portion.

What backup/recovery option have you in place.  This can affect your database size.

is it near EXAM time???

"5 million records should take 5 minutes or less for BCP....."....you missed out on the provisio....'depending on your hardware'.  Nowhere is the hardware/disksubsystem described...this has some impact on the performance (probably...

"Just simply replace the WHILE clause by IF"...

so bleeding obvious!...a very good lesson in standing back and keeping it simple

Is the execution plan the same for both runs?

The truncate may cause a re-compilation of the SP.

The following works....I think the problem is to do with resetting your looping variable.  Also nulls in results/variables  are very difficult to work with!

CREATE proc ShowHierarchy

 @ParentID int,

 @inplacement int,

 @outplacement int =...

The real issue for you to sovle is getting a field which will hold an accurate and predicatable PK.  If the size of the field matters, then use a char(x)...

Only issue is if you need to apply indexes for performance....can you index (and benefit from an index on) a #table?

You could always go for the 'cheap' option of copying backups onto a reporting database once/twice a day.....if 100% uptodate is not necessary.

Your approach seems right....the hard part though is finding a "an english-style collation" that will match up your accented characters.

The alternative is to 'attempt' top remove all possible known accented...

Your approach seems right....the hard part though is finding a "an english-style collation" that will match up your accented characters.

The alternative is to 'attempt' top remove all possible known accented...