in reply to sth->execute returns undef when successful

Disclaimer: I don't use Oracle. Just throwing out a couple of questions since you haven't received an answer yet.

It looks like you are using threads. Could that be the reason why there are problems with long queries and not with simple ones? From the DBI docs: "Using DBI with perl threads is not yet recommended for production environments. "

Is your statement really CREATE (out0, lob0) ...? Don't you need to say CREATE TABLE tbl_name (col_name ... )?

Doesn't seem like it would make a difference here, but why not use RaiseError ?

Hope this helps a little.

The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^2: sth->execute returns undef when successful
by BrowserUk (Patriarch) on Aug 08, 2015 at 18:10 UTC

    1. "Using DBI with perl threads is not yet recommended for production environments. "

      Do you have any first hand experience of use DBI with threads?

      Because citing decade old scaremongering quotes from docs that never get updated -- when there are thousands of people using DBI in conjunction with threads -- isn't useful.

    2. Could that be the reason why there are problems with long queries and not with simple ones?

      Care to explain the logic behind that piece of deduction?

    3. It looks like you are using threads

      The fact that the version of perl (and thus the version of DBI) was built with threading enables, does not mean "he's using threads". Neither do the presence of thread handles in the traces.

      That simply means that he could (safely) use threads if his application required it.

      If you look closely at those traced thread handles, you'll see they are all the same! So, at least the bit traced, is single threaded.

    Bottom line: speculations on subjects you appear to know little about and have personal bias towards doesn't help anyone.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
    I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]
[d/l]

      Ouch. No personal bias, I am not one of those anti-thread boogeymen, and I tried to preface my comment appropriately, asking questions, not making statements. What do you think the problem is?

      The way forward always starts with a minimal test.
[reply]
[d/l]
        What do you think the problem is?

        I really have no idea, hence why I've not posted.

        From the trace it looks like the call to the db completed successfully: "dbd_st_execute CREATE returned (SUCCESS, rpc2211750915, fn1, out0)" which probably points to a bug in the DBI/Oracle driver.

        I think the OP will need advice from a DBI/Oracle expert.

        Though I do wonder if this might have something to do with it:

        "For a non-SELECT statement, execute returns the number of rows affected, if known. If no rows were affected, then execute returns "0E0", which Perl will treat as 0 but will regard as true. Note that it is not an error for no rows to be affected by a statement. If the number of rows affected is not known, then execute returns -1."
        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]

In Section Seekers of Perl Wisdom