Post reply

SQLSTATE 01000 Message?

  • October 6, 2004 at 7:20 am

    #85615

    I was running a stored proc via a job that updates a table.  I get his error a few hundred thousand records in ... any idea what is up?

     

    Executed as user: DTSRV\OwnerofProc. ...E 01000] (Message 0)  Updating: 3 [SQLSTATE 01000] (Message 0)  Updating: 4 [SQLSTATE 01000] (Message 0)  Updating: 5 [SQLSTATE 01000] (Message 0)  Updating: 6 [SQLSTATE 01000] (Message 0)  Updating: 7 [SQLSTATE 01000] (Message 0)  Updating: 8 [SQLSTATE 01000] (Message 0)  Updating: 9 [SQLSTATE 01000] (Message 0)  Updating: 10 [SQLSTATE 01000] (Message 0)  Updating: 11 [SQLSTATE 01000] (Message 0)  Updating: 12 [SQLSTATE 01000] (Message 0)  Updating: 13 [SQLSTATE 01000] (Message 0)  Updating: 14 [SQLSTATE 01000] (Message 0)  Updating: 15 [SQLSTATE 01000] (Message 0)  Updating: 16 [SQLSTATE 01000] (Message 0)  Updating: 17 [SQLSTATE 01000] (Message 0)  Updating: 18 [SQLSTATE 01000] (Message 0)  Updating: 19 [SQLSTATE 01000] (Message 0)  Updating: 20 [SQLSTATE 01000] (Message 0)  Updating: 21 [SQLSTATE 01000] (Message 0)  Updating: 22 [SQLSTATE 01000] (Message 0)  Updating: 23 [SQLSTATE 01000] (Message 0)  Updating: 24 [SQLSTATE 01000] (Message...  The step failed.

  • October 11, 2004 at 8:00 am

    This was removed by the editor as SPAM

  • October 11, 2004 at 10:08 am

    #526205

    Does it do this if you run it interactively? Can you double click the failed item and get an error?

    Most likely it's a data problem. Try changing the first and last rows and see if you can pinpoint the problem.

  • October 11, 2004 at 10:25 am

    #526209

    Does it do this if you run it interactively? Yes.

    Can you double click the failed item and get an error?  Yes (Error was in the original posting)

    The only other activity on the server is the creation of index's.  DBA's watch and if processes are running slow against a table they create index's on the fly.  Could this be hurting me ... is there a safe way to do this? 

    Thanks so much for replying.

  • October 11, 2004 at 10:35 am

    #526212

    Thats not an error.  SQL adds that at the end of a print line.

    It looks like you have something like 

    PRINT 'UPDATING: " + cast(@count as varchar(3))

    in your stored procedure.  Nothing to worry about.

    Steve

  • October 11, 2004 at 10:47 am

    #526214

    I found the PRINT statement.  Why would that cause the error I received?   I took the print out and things run fine now.

  • October 11, 2004 at 10:59 am

    #526219

    Again, its not an error message.  Its like an "aknowledgement" that SQL is preforming a print command.  Anytime you put a PRINT command in a stored procedure, you're going to see that in the output.  Its ugly, but I don't know of any way to get rid of it. There have been several discussions here on SQLServerCentral.com about it, but I haven't seen any way of suppressing it.

    Steve

  • October 11, 2004 at 11:00 am

    #526220

    By the way, if that update count is useful to you, you can put it back in. The 01000 message doesn't hurt anything at all.

    Steve

  • May 25, 2005 at 7:12 am

    #560939

    Hi. l tried this command in a job (SQL Agent , not Stored Procedure) and l have the same problem. The result for the job ends up in a file.

     

    Print '------------------------------------------------- '

    GO

    Result:

    Job 'test' : Step 1, '1' : Began Executing 2005-05-25 13:44:21

    ------------------------------------------------- [SQLSTATE 01000]

     

    In Query Analyser l do not have this problem.

    Suggestions?

  • May 31, 2005 at 9:06 am

    #561910

    My suggestion is to either ignore it or take out the PRINT statement.  It doesn't hurt anything.  Your job functions the same with or without it.  Its just an informational message to let you know that SQL processed the PRINT statement.  As far as I know, there is no way to get rid of it except taking out the PRINT statement.

    Steve

  • May 2, 2007 at 2:22 pm

    #703927

    Easy way is just put '--' into your PRINT

    PRINT 'UPDATING: " + cast(@count as varchar(3))'

    AS

    PRINT 'UPDATING: " + cast(@count as varchar(3)) --'

    So that,[SQLSTATE01000] will be --[SQLSTATE01000], is commented out.

  • August 24, 2007 at 10:04 am

    #729332

    Thank you folks. I was going nuts over a similar message from my SQL scheduled job.

    Executed as user: MXIMACOLA\Administrator. ... 1 completed 36938 [SQLSTATE 01000] (Message 0) Step 2 completed36938 [SQLSTATE 01000] (Message 0) Step 3 completed 36938 [SQLSTATE 01000] (Message 0) Step 4 completed 36938 [SQLSTATE 01000] (Message 0) Step 5 completed 15002 [SQLSTATE 01000] (Message 0) Step 6 completed 15002 [SQLSTATE 01000] (Message 0) Step 7 completed 15002 [SQLSTATE 01000] (Message 0) Step 8 completed 15002 [SQLSTATE 01000] (Message 0) Step 5 completed 36939 [SQLSTATE 01000] (Message 0) Step 6 completed 36939 [SQLSTATE 01000] (Message 0) Step 7 completed 36939 [SQLSTATE 01000] (Message 0) Step 8 completed 36939 [SQLSTATE 01000] (Message 0) Step 5 completed 36940 [SQLSTATE 01000] (Message 0) Step 6 completed 36940 [SQLSTATE 01000] (Message 0) Step 7 completed 36940 [SQLSTATE 01000] (Message 0) Step 8 completed 36940 [SQLSTATE 01000] (Message 0) Step 9 started UID Capture=36938 [SQLSTATE 01000] (Message 0) Step 10 completed 50247 [SQLSTATE 01000] (Message... The step failed.

    I am gonna take out the print statements and see if the job status shows up as succeded the next time it runs

  • November 23, 2008 at 1:10 am

    #902151

    use set ANSI warnings off before u write job execution step exec job name & set ansi warnings on job execution step.

    it will resolve ur problem.

    syntax

    SET ANSI_WARNINGS OFF

    GO

    exec SERVICE_RESUB

    go

    SET ANSI_WARNINGS ON

    GO

    🙂

    I'm sure this will work....

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply