try this and look at the results:

SELECT *

FROM GRADSTUDENTS G

FULL OUTER JOIN TA T ON G.LOGINID = T.LOGINID

--WHERE G.LOGINID IS NULL

--WHERE T.LOGINID IS NULL

the first rows in...

it has to do with mix mode being allowed or not. on express, it's turned off by default, but usually on for production servers.

1) Open up SQL Server Management Studio...

when you get a problem where it say find data that is NOT [whatever]

you typically need to use a LEFT OUTER JOIN, instead of an INNER JOIN

the word "join" in...

I'm just guessing, but it might be the size of the variable being passed; I'm also assuming your not using the fnParseRTF, since that doesnt need CLR or OLE.

add this...

it might be that all your objects are not owned by dbo.

you might have tables that need to be referenced by mike.tablename or webdev.tablename, for example .... instead of just...

Similar to what someone else posted, this procedure "UGLYSEARCH" is not for use on a production box...if you have a database with 50K columns that are varchar, etc, this is...

sp_executesql is probably being used after building a dynamic sql string...

the inherent problem with that is you could execute a command which makes data changes, but makes so many changes...

you could try the stored proc sp_fkeys [tablename]

that will list all the tables that reference any column in the selected table via a foreign key reference...

if you ment a GUI...

doesn't matter which version of SQL; the script at that link is 2000/2005 compatible.

download the script form the link I posted...it's basically CREATE FUNCTION ProperCase AS....

open SQL Query Analyzer,...

well let me be more detailed: only one server can use the actual .mdb and ldb files at any one time. restored databases were just copies of hte current data.

1.first...

no problems at all; we had both servers up and running at the same time for a week; the databases we detatched and reattched were developer databases, so they had...

just to be sure, can you exec sp_help History and also exec sp_help LM_Date1 so we can be sure the columns H.Paid_Date and LM_Date1.Paid_Date are both datetime?

We recently upgraded, but we did not do it the way you described.

we brought up a new server, and made sure it had access to the san.

depending on the database,...

the only way i see that happening is if the columns with the date is being treated as a varchar...but you said you were sure the fields were datetime data...

i think it's because the script was generated in compatibility 90 syntax, but you are creating the table in V80:

i think this part is not 80 compatible on line 35...