ok, run this to find the current recovery interval setting:

USE master;

GO

EXEC sp_configure 'show advanced option', '1';

RECONFIGURE;

EXEC sp_configure;

USE master;

GO

if needed, lets set the interval to a shorter time

--The following example sets...

I doubt very much the issue is CHECKPOINT not running.

I'll bet your database is set to Recovery Mode = FULL, and you are not taking regular transaction log backups, so...

don't you just need to compare the convert of the column to itself to see if they are not equal to find items that are not in range?

something like

select...

there is a project on codeplex to help do this kind of thing in either direction; i downloaded it but did not test it yet, but it might help you...

so, do the calulation from stratchpad2 every time, but items in sp4 are only sometimes there...

like this?: (new calculation for "specminutes")

SELECT

name,

employeenumber,

summinutes,

sum(summinutes/60) as...

I *think* the OP is...

there's an inner join in your query, which would limit the data to only the employee's that exist in BOTH tables...is that what the problem is?

...

inner join scratchpad4

on scratchpad2.employeenumber =...

dates have to be encased is single quotes, as they are not a number.

instead of this:

<= 01/31/2011

--change to this for example

<= '01/31/2011'

change it everywhere you had date strings.

this command seems to be working for me to return results on a per-db basis...is that what you wanted?

sp_msforeachdb

'select ''?'' as dbname,*

from sys.dm_db_index_usage_stats

where database_id = db_id(''?'')'

help us help you...when i read your question, i think the question is "when i profile my procedure, it never finishes. when i just run it, it is fast"

is that...

in 2005 and above, there is a DMV that has the IP address, but note it's possible the value ls '<localhost>' or null if they connected via shared pipes.

...

wow, so even if you were to drop the table itself in the original database, the space will not be recovered? is that right?

no, removing ad hoc will not affect your replication.

in 2008, it's a right click with the SSMS object explorer on the server and go to "facets": disable these two items...

could you be trying to connect with a lower version of SSMS, for example the Express Version that comes with Advanced Services?

That limited, express version does not let you connect...

not without something keeping track of those references;

object dependancies are limited to exist inside a database...that way if you backup and restore, everything your object referenced are together.

because multiple databases...