Can you tell us why you need to have a column point to 2 different foreign keys? I cannot imagine a situation where I would have to do this...

Select * from objsql where exists (Select * from dbo.SysObjects) != 0

Serveur : Msg 170, Niveau 15, État 1, Ligne 1

Ligne 1 : syntaxe incorrecte vers '!'.

you can't have !=...

I already saw that once. I was using a memo field. This bug occured when that memo field suddenly grew from only a few bytes to a few...

OK, OK... I was wrong. Access can run faster than SQL server under certain circumstances .

1 - You don't need a temp table to execute that select (unless you plan to alter that data somehow or need to reuse it later in the proc before...

Where there's a will, there's a way but we need to you the ddl of the tables along with the relations and the indexes if we can be of any...

Can you post the whole select?

I think you're gonna have to use my select as a derived table and use that table to join to your main select to give...

Just went a little overboard... I guess I love sqlserver too much.. but my point is that under the same networking condition, sql server will not be slower than access.

UPDATE

pos

SET

pos.prev_yield = prev.prev_yield

FROM

@tbl_Position_Previous_Day prev inner join

@tbl_Position pos

on

prev.sec_id

= pos.sec_id

AND

prev.tick_lot

= pos.tick_lot

inner join @Table3 T3 ON T3.id = pos.id

Yes because SQL server when working with a normalized and well indexed db will ALWAYS FLAT OUT CRUSH ACCESS... unless the network or something out of his control stop it...

Check the execution plan of view a and check for bottlenecks and report back to us. It's most likely a sort that is being rerun too often or a...

Something like this?

Select 'CURRENT' as "Year", sum(orders) from dbo.Orders where OrderDate between @DateStart and @DateEnd

UNION ALL

Select 'LAST' as "Year", sum(orders) from dbo.Orders where OrderDate between

DATEADD(yyyy, -1, @DateStart) and

DATEADD(yyyy,...

np... I could have been wrong too... or it could have been simply the selectivity of the index that changed the whole thing. At least we both learned something...

HTH... too bad my last idea couldn't work in this case. I guess checking if a search like the current one has been cached, and adding where conditions to...

It just becomes a 3 tables joins... you should be able to figure it out .