Make sure you have a backup of the corrupted db... might come in handy after the decompile (can save you, but it can crush whatever's left of the db too,...

Is it just me or you seem to be the expert on jobs offering??

Select user_name()

That will give you the current context of the connection... Make sure that this user has execute permission on the proc.

That too .

Is this what you are looking for?

Select L.Name AS Owner, J.* from msdb.dbo.SysJobs J inner join Master..SysLogins L on J.owner_sid = L.sid

And now you have a proof... 1 = 0.  Looks like those users were right all along .

try Exec dbo.MyProc

Also make sure that the user has exec permission on the procedure.

Who owns the procedure?

Does the application user has execution rights on the procedure?

What code are you using the call the procedure ( exec myproc or exec Claves.myproc)?

I think you have to restart the service to correct that problem!!  Wait for a confirmation before doing so (unless the server is not in production)... I ain't 100% sure...

I wouldn't call it careless, maybe caffeineless .

... or use Xp_ExecResultSet (works only for 2000, not for 2005).

Is this a one time deal or permanant maintenance of the DB?

To reply to the isnumeric problem :

IF EXISTS (SELECT * FROM dbo.SysObjects WHERE XType = 'FN' AND Name = 'fnIsAllNumbers')

 DROP FUNCTION dbo.fnIsAllNumbers

GO

CREATE FUNCTION dbo.fnIsAllNumbers (@Str AS varchar(8000))

RETURNS INT

AS

BEGIN

 RETURN (SELECT...

Yup and here's the script I always post :

IF Object_id('ListTableColumns') > 0

 DROP FUNCTION ListTableColumns

GO

CREATE FUNCTION dbo.ListTableColumns (@TableID as int)

RETURNS varchar(8000)

AS

BEGIN

 Declare @Items...

What's the exact name of the DB?

Try manually creating a directory with that name and see if windows lets you (forbidden character is what I would assume at this point).