In a stored procedure I'd like to get the call hierarchy like it's shown in the tab "Call Stack" when debugging with Sybase Central.

I remember having seen a system procedure or function for that, but I can't seem to find it. Can annyone point me to that procedure (or tell me my memory is wrong)?

asked 22 Feb '13, 06:52

Reimer%20Pods's gravatar image

Reimer Pods
4.2k334481
accept rate: 12%


Are you looking for the following system function?

select traceback();
permanent link

answered 22 Feb '13, 07:02

Volker%20Barth's gravatar image

Volker Barth
30.3k300452659
accept rate: 32%

edited 22 Feb '13, 07:15

Thanks Volker, that's what I was looking for. But not remembering how it's called I couldn't find any trace of it ;-)

(22 Feb '13, 07:52) Reimer Pods
Replies hidden

Volker's answer helped me find the function I've seen before. But to my disappointment it's only result is the SQL command that was executed when an error occured.

What I had in mind, was getting informations about where the error occured (procedure or trigger). But I suppose that there exists not such function, or am I wrong?

(22 Feb '13, 09:10) Reimer Pods
Replies hidden

Well, at least we can tell you your memory is not wrong:)

(22 Feb '13, 09:36) Volker Barth

The next version (aka Nagano) has new-and-improved error reporting & traceback functions, so check out the beta if you haven't already.

(22 Feb '13, 09:40) Mark Culp

Thanks, Mark, I will check the new features.

(25 Feb '13, 08:00) Reimer Pods
Replies hidden

One workaround I have thought of (but don't know whether it would work at all, and it would require work...):

  • Add an execption handler in each relevant procedure (in case you've not done that)
  • Inside the handler, use TRACEBACK() to get the last local statement (in case it will really show that) and message that to the log or somewhere else.
  • Re-signal the error...

As stated, I don't know whether this will work, and of course the "re-signal" would possibly interfere with the attempt to handle errors locally...

(25 Feb '13, 08:06) Volker Barth

Volker, thank you for the suggestion. The hard part is the "relevant procedure" as that is exactly what I'm wanting to find out. The database for that application has ~600 SP and ~400 triggers created over the last 15 years, many of them lacking proper error handling.

So my next step will be to try the-soon-to-be-released-version of SA (kind of "He-Who-Must-Not-Be-Named" ;-)).

(25 Feb '13, 08:47) Reimer Pods
Replies hidden

TRACEFORWARD(), as they say:)

(25 Feb '13, 09:04) Volker Barth

Well, I tried TRACEBACK () in Nagano beta, but to no avail, it does exactly the same as SA12, just shows the line executed when the exception was fired. So maybe the documentation is ahead of the beta release ...

(26 Feb '13, 05:07) Reimer Pods
Replies hidden

Reimer: Note that the traceback() and error_*() functions only provide useful information if used within an exception (or catch) block. Once the stack has unwound the information is no longer available.

(26 Feb '13, 09:11) Mark Culp
showing 5 of 10 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×102
×31

question asked: 22 Feb '13, 06:52

question was seen: 1,095 times

last updated: 26 Feb '13, 09:11