Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. Capture error return by MS Sql

Capture error return by MS Sql

Scheduled Pinned Locked Moved Database
databasequestionsql-servercomsysadmin
6 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H Offline
    H Offline
    Hum Dum
    wrote on last edited by
    #1

    Reading excel file with OPENROWSET of sql server. Working fine and getting values. Now, if the file which i am reading is in use (opened), it gives error. How should i capture this error, I tried

    Declare @error varchar(50)
    SELECT *
    FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
    'Excel 8.0;Database=\\webex\cis\CIS overview.xls',
    'SELECT * FROM [CIS Overview$]')

    IF(@@error <> 0 )
    BEGIN
    Set @error = 'Error reading file'
    RETURN
    END

    But its not even reaching to IF clause, terminate giving message

    OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IDBInitialize::Initialize returned 0x80004005: The provider did not give any information about the error.].
    Msg 7399, Level 16, State 1, Line 3
    OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error. The provider did not give any information about the error.

    How can i capture this error ? reagards

    W 1 Reply Last reply
    0
    • H Hum Dum

      Reading excel file with OPENROWSET of sql server. Working fine and getting values. Now, if the file which i am reading is in use (opened), it gives error. How should i capture this error, I tried

      Declare @error varchar(50)
      SELECT *
      FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
      'Excel 8.0;Database=\\webex\cis\CIS overview.xls',
      'SELECT * FROM [CIS Overview$]')

      IF(@@error <> 0 )
      BEGIN
      Set @error = 'Error reading file'
      RETURN
      END

      But its not even reaching to IF clause, terminate giving message

      OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IDBInitialize::Initialize returned 0x80004005: The provider did not give any information about the error.].
      Msg 7399, Level 16, State 1, Line 3
      OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error. The provider did not give any information about the error.

      How can i capture this error ? reagards

      W Offline
      W Offline
      Wendelius
      wrote on last edited by
      #2

      You can use try..catch in T-SQL also. Refer to: TRY...CATCH (Transact-SQL)[^]

      The need to optimize rises from a bad design.My articles[^]

      H 1 Reply Last reply
      0
      • W Wendelius

        You can use try..catch in T-SQL also. Refer to: TRY...CATCH (Transact-SQL)[^]

        The need to optimize rises from a bad design.My articles[^]

        H Offline
        H Offline
        Hum Dum
        wrote on last edited by
        #3

        Any other Light ? As i am using sql 2000 :^)

        W 1 Reply Last reply
        0
        • H Hum Dum

          Any other Light ? As i am using sql 2000 :^)

          W Offline
          W Offline
          Wendelius
          wrote on last edited by
          #4

          Okay, and you're sure the IF is not hit at all... One thing you could try is to call this procedure from another and check if you can handle the error properly in the calling procedure.

          The need to optimize rises from a bad design.My articles[^]

          H 1 Reply Last reply
          0
          • W Wendelius

            Okay, and you're sure the IF is not hit at all... One thing you could try is to call this procedure from another and check if you can handle the error properly in the calling procedure.

            The need to optimize rises from a bad design.My articles[^]

            H Offline
            H Offline
            Hum Dum
            wrote on last edited by
            #5

            Mika Wendelius wrote:

            you're sure the IF is not hit at all...

            Well instead of if you can use PRINT, if control reaches to print it should print. But execution terminates on OPENROWSET itself.

            Mika Wendelius wrote:

            call this procedure from another and check if you can handle the error properly in the calling procedure.

            No luck ! in a new query window i tried like

            EXEC [spName]

            IF(@@error <> 0)
            BEGIN
            Print 'No error'
            END
            ELSE
            BEGIN
            Print 'error'
            END

            here also not going to if clause ! Any other suggestion?

            W 1 Reply Last reply
            0
            • H Hum Dum

              Mika Wendelius wrote:

              you're sure the IF is not hit at all...

              Well instead of if you can use PRINT, if control reaches to print it should print. But execution terminates on OPENROWSET itself.

              Mika Wendelius wrote:

              call this procedure from another and check if you can handle the error properly in the calling procedure.

              No luck ! in a new query window i tried like

              EXEC [spName]

              IF(@@error <> 0)
              BEGIN
              Print 'No error'
              END
              ELSE
              BEGIN
              Print 'error'
              END

              here also not going to if clause ! Any other suggestion?

              W Offline
              W Offline
              Wendelius
              wrote on last edited by
              #6

              Hmm, what happens if you try to execute the statement dynamically. Put it into a string and then use exec to run the statement. Unfortunately I don't have SQL Server 2000 to test this issue...

              The need to optimize rises from a bad design.My articles[^]

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups