Same as normal tables I guess. (available storage)

They are only recommended when the expected number of records will be low.

(due limitations like no indexing ...)

The actual "start" values are mostly in the RPC starting and SQL Batch starting events.

The different computernames can cause issues.

Should be visbible in the version number

SELECT @@VERSION

or

execute xp_msver

List of version numbers:

http://www.sqlsecurity.com/FAQs/SQLServerVersionDatabase/tabid/63/Default.aspx

My apology for the pause.

Have a look at the end of

http://www.macronimous.com/resources/stored_procedures_for_ASP_and_VB_Programmers.asp

or

http://msdn.microsoft.com/en-us/magazine/cc163987.aspx

A more elaborate version inside the stored procedure:

http://www.novicksoftware.com/coding-in-sql/Vol3/cis-v3-N12-making-stored-procedures-readable.htm

You're welcome

Vacation is vacation. You could be anywhere on the planet, with an empty battery.

Is the exe on a local drive (E:...)

or a network drive \\otherserver\myexe (not accessable by local machine)?

You could check hardware logs/application logs.

You could create views/storedprocedures on DB2 for the data you need to fetch from DB3.

Error handling in sql 2000 is a tricky process.

You have to evaluate after each statement. Some errors immediately abort the batch.

statement

/*saving the error*/

@myvar=@@error

if @myvar<>0

BEGIN

doerrorhandling

END

statement

@myvar=@@error

if @myvar<>0

BEGIN

doerrorhandling

END

Inside the...

Perhaps a security issue of sqlagent. What is its windowsaccount? Local machine, ...

Is the update being done with .Update (can be slow) or with an update-sql statement?

Adding some code to quickly scroll to the bottom and back up?

It is affected by the number of records.

Do you have a covering index on (stime,savg) to avoid bookmark lookups?