in reply to What's in a DBI statement handle?

If you really must find out, you can use Data::Dumper to examine the contents. It can even be a quick one-liner:
use Data::Dumper; print Dumper($sth);
I think the reason you are missing data is because you just created a $sth out of thin air, and not throught the proper factory method, which presumably has access to additional data.

Either way, any information you discover with this or other methods is considered classified. It might change. It might become French or Swedish at the whim of the programmer, and if your program breaks when they do, that's the price you pay. NAME one day and BORK the next, you never know. After all, that kind of change won't break any programs that follow the guidelines in the documentation.

There is probably a reason why it is not exposed with a proper method, but this could be almost anything. DBI is used on a lot of different things.

Replies are listed 'Best First'.
Re: Re: What's in a DBI statement handle?
by lachoy (Parson) on May 17, 2002 at 16:09 UTC

    Unfortunately, this won't work -- you'll get the Data::Dumper equivalent of what rinceWind showed. Since the statement handle is a tied hash and the DBI is ultra-concerned with efficiency and speed, the properties don't actually get filled until you call them. Best bet is to read the docs.

    Chris
    M-x auto-bs-mode

[reply]
      So DBI hides the keys it contains?

      Yves / DeMerphq
      ---
      Writing a good benchmark isnt as easy as it might look.

[reply]

        Right -- more specifically: as a tied hash it does not implement the FIRSTKEY and NEXTKEY methods to list the attributes supported. There's probably a very good reason for this -- many implementation behaviors in the DBI may seem weird at first but on further inspection make a lot of sense.

        Chris
        M-x auto-bs-mode

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom