I looked up reading and writing images to and from the database, because I think the concept would be similar. A nice explanation with some C# code is here:

an alternate solution:

create table #test(PersonID int, [Value] int, Altvalue int)

Insert INTO #test

Select 1, null, 6

union all select 1, null, 6

union all select 1, null, 6

union all select 1, null, null

union...

The DISTINCT keyword is the same as a group by with no aggregates. I don't know if it's faster or not.

This is what he is saying:

set @sql_str='select * from mydatabase.dbo.mytable'

If you fully qualify the tablename prefixed with the database, you can execute against that table regardless of the connection context...

Go to Tools|Options|Results tab

and set the max characters per column value higher...

Mahesh, I disagree. From what I understand, the query optimizer will determine which table to select from first. I've experimented with changing my join order around, and the query plan...

You'll have to make it a dynamic query. That is, build your sql string, and execute it

declare @sql nvarchar(max)

Set @sql = 'update ' + @tablename...

And if you forget a condition in your where clause linking two of the tables together, it is an implicit CROSS JOIN.

Hmmm. Since the columns are the same across the two, I'd create one table, and simply have another column indicating "type" whether it be a numeric value(1,2) or a char(1)...

1. Tables scans are bad. Maybe some indexes on the temp tables depending on how large they are.

2. Joining to table valued functions can also significantly impact performance.

We went down...

Hmmm...or more circuitously:

Select * From table where len(myColumn) + 1 <> len(myColumn + '.')

I'm sure there's a flaw in my logic here, but the idea is to exploit the behavior...

I believe that the temp table will stay there as long as you have the SSMS window open, which is why when developing, I always put the drops in so...

you can research the AVG and MAX aggregate functions. There are plenty of samples in BOL.

If I'm not mistaken, #temp table are implicitly dropped at the end of the stored procedure regardless of whether or not you explicitly drop it. ##temp tables (global ones) must...

It's efficient when your users aren't complaining that its slow 🙂