It should be 3859 and 3860 are not there.

Here is my test case.

select * from call

CallID      ProspectID  TerminationCode Uploaded

----------- ----------- --------------- --------

112         3859        a               N

119         3860        a               N

116         3861        a               N

120         3862        a               N

118         3870        a              ...

Can you post a sample with Caps which should be reserved?

create function fn_pickup (@ProspectID int, @CustCredAct varchar(11))

returns bit

as

begin

 declare @return bit

 set @return = 1

 if exists(

 select * from call a

   inner join Prospect b on a.ProspectID = b.ProspectID

   where b.CustCredAct =...

select a.ProspectID

 from call a

 inner join Prospect b on a.ProspectID = b.ProspectID

 inner join call c on b.CustCredAct = c.CustCredAct

 where a.callid = (select max(d.callid) from call d where a.ProspectID = d.ProspectID)

 and exists(select...

tempdb and log file(s) on the faster driver.

sp_cycle_errorlog can be used to avoid modify the errorlog.

Only if error happen a lot, you will lose history.

Relationship does not directly affect performance.

Primary key by default will have unique index which has big impact on performance, but one can put unique index without primary key to...

Only happen when outside table column name (exists)= inside column name (not exists)

select * from from table1 where colname in (select colname from table2)

It is correct for following

select...

According to data storage length, bigint will be faster.

In most case, no, unless query optimizer can not use it efficiently.

Alwayse verify with execution plan.

Use timestamp in pre-trigger is a way.

bug fix.

create function fn_reverse (@strin varchar(4000))

returns varchar(4000)

as

begin

 declare @return varchar(4000)

 declare @ascii smallint, @numeric bit, @space smallint, @start smallint, @garbage varchar(30)

 declare @i smallint, @j-2 smallint

 select @i = 1, @start =...

BOL (book on-line) is quite useful.

This error means data type mismatch.