Thanx. The most I can say is you need a backup or a log explorer to rollback the changes... that's not much help when you're in that much troubles......

Are you calling the proc with owner.procname?

Is it possible that this proc is calling a proc that is missing?

Strange... it's possible to change that in access (design time, not runtime).

Also once this crisis is over you'll surely be interested in reading this thread :

The DBA Whoops

check if you can rewrite the query to use the index in the best way possible. if you can't then see if you can't change the indexing strategy.

Could you guys check out this thread, he badly needs help that I can't offer :

ACCIDENTALLY REWROTE THE PRODUCTION DATABASE

I always work with the worst case scenario in those situation... so let's assume it takes all numbers to arrive at the sum...

also is it possible to use the same...

Can you just change the size of that section?

I can't answer that one... probabely someone else may be able to on this site. However a log reader like log explorer might be able to undo the damage...

Maybe something like this :

create table #ids( n int,name varchar(20))

insert into #ids (n,name) values (7534,'tt')

insert into #ids (n,name) values (7535,'tt')

insert into #ids (n,name) values (7536,'tt')

insert...

You're the programmer, you must give them what they need, not what they want. They need to be able to do X, then let 'em do X but it doesn't...

Simple... but I just hope that they have a monser of a machine to make all those calculations .

How about making sure that the server never has an outage by having redundant power sources, and one battery that can make it work just long enough that you can...

Can you see the execution plan of the trigger and find what part of it is causing the slowing down?

Also I would strongly suggest that you encapsulate the whole trigger...

Do you have a backup of the production database and of the transaction log??