On Tue, Sep 2, 2014 at 11:01 AM, David Wagle <david.wa...@gmail.com> wrote:

> It sounds like perhaps the issue is code blocks with a long run-time that
> may or may not fail or hang in some way?
>
> If that's the case, the solution is probably simply breaking up your code
> blocks into smaller bits of code so that you more easily follow what's
> happening.
>
> If the code is emacs-lisp, it's easy enough to put (message ...) calls
> entering and leaving the code blocks.
>

The defadvice idea is great; I will try it and report back.  As for
breaking up my code blocks... I wish I could, but some of my SQL queries
are just very long running.  We have a lot of data.  I want to look into
indexing and other SQL optimizations -- but I need something in my org-mode
to at least show me which blocks are the long-running ones, so I can know
where to start!

Someone else mentioned that the message about "Wrote <sql input file>"
could be suppressed; just don't forget that we users need _something_ to
help debug our babel code.  If one of my sql queries goes wrong, I get
something like this in the messages buffer:

executing Sql code block (machines-by-week)...
mysql  ... -N  < "c:/tmp/babel-26204dNc/sql-in-26204uKN" >
"c:/tmp/babel-26204dNc/sql-out-262047UT"
Wrote c:/tmp/babel-26204dNc/ob-input-26204IfZ
Babel evaluation exited with code 1

so in this case it'd be OK if the "Wrote <file>" went away, because the
entire mysql command is still there, so I can find that temp file (which
babel doesn't clean up, btw, and in my case that's a good thing!) and trace
it back to which code block it came from.

But it would be way better if mysql-mode would actually show the sql error!

-- 
Gary

Reply via email to