Re: perl pad.c Assertion !((sv)->sv_flags & 0x00010000) failed
On Thu, 21 Jun 2007 22:33:03 +0100, Tim Bunce wrote:
> On Thu, Jun 21, 2007 at 06:47:11PM +0200, Rafael Garcia-Suarez wrote:
>> On 21/06/07, Steve Hay <[EMAIL PROTECTED]> wrote:
>> >I remember lots of discussion a while ago about constructions like "my
>> >$x = 1 if $y;". I don't remember what the conclusion of it all was,
>> >except that it's probably best avoided. Is that right?
>>
>> Yes, that's right, because that could bypass initialisation of $x if
>> $y is false, leaving the previous value in it, like in state vars.
>
> I thought that issue only related to a "compile-time constant false"
> (such as the one in your example) and not to a runtime expression that
> happened to be false sometimes.
>
> Looking at it another way, are you saying that (ignoring closures)
> subroutine scoped lexicals are not cleared when the subroutine exits,
> but persist (consuming memory) until the subroutine is reentered?
$ ./perl -wle '$q = shift; sub foo { my $x if $q; print $x // $]; \
$x = 42 } foo; $q++; foo' 0
5.009005
42
It looks like it, no?
--
Peter Scott
Re: Duplicate table structure
On Thu, 07 Jun 2007 08:47:00 +0200, Dr.Ruud wrote: > Peter Scott schreef: > >> Is there a simple way to create a new table with the same structure >> as a given one in a *different* database? That means the CREATE >> TABLE foo AS SELECT * FROM bar WHERE 1=2 method won't work. > >> I'd need to have two database handles open. >> They're both Oracle > > I suppose the DBD can give you enough information on the table to > generate a CREATE statement from that. Yes, it does. I ended up taking the output of DESCRIBE and tweaking it a little. I was just using the opportunity to wonder if there was an even lazier way. The suggestion of another poster to use dbms_metadata (see, e.g. http://builder.com.com/5100-6388-5054021.html) was a good one; I'd not heard of it before. If I have to do more than just column type definitions, or multiple tables, in the future, I'll definitely check it out. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
Duplicate table structure
Is there a simple way to create a new table with the same structure as a given one in a *different* database? That means the CREATE TABLE foo AS SELECT * FROM bar WHERE 1=2 method won't work. Didn't find anything in some searching. I'd need to have two database handles open. They're both Oracle, but there's no chance of a cross-database link here. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
Re: [VPM] [RFC] naming a module for SQL routines
At 12:04 AM 9/18/2004, Darren Duncan wrote: The main reason concerns a revisiting of one of the module's main intended uses, which was to support the idea of any database-related activity being representable by a SQL routine or imitation thereof. An implementation of a SQL routine that my module describes/models/defines could either be stored in a database schema (eg: as a SQL stored procedure, function, or trigger), or it could be stored on the client/application side (eg: as a fusion of Perl code and DBI calls). But from the application's point of view, the routine simply exists in a locally addressable space and can be invoked more or less like a Perl routine (function or procedure), regardless of whether it is actually in the database or on the client. A routine is quite generic in scope and can hold complete instructions for any kind of database activity, including arbitrarily complex select queries, DML, schema creation or manipulation, user management, transactions, and connections. Therefore, saying that my module supports or models routines means that it supports and models all types of SQL. It was also designed in the hindsight of SQL-2003, and is not limited to SQL-1992. This is a bit off the wall, but after giving this considerable thought, what comes to mind is SQL::Mechanize, after WWW::Mechanize. But while my module can represent SQL effectively, it is not exactly the same as SQL, and can be used with both databases or applications that don't want to talk SQL. Hence, calling it a "SyntaxModel" is somewhat archaic. Given this, perhaps DBIx::Mechanize would be more appropriate. YMMV. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/
Non-blocking DBD::Oracle connections?
I have an Oracle account which is restricted to one simultaneous
connection at a time. Attempts to exceed this number result in
the later attempts blocking until the first connection is terminated.
Is there anything in DBD::Oracle that can check for this so I can
say, "Sorry, try again later?" Or just the usual $SIG{ALRM}/eval
approach?
--
Peter Scott
http://www.perldebugged.com
Re: DBI vs. piping query to Mysql
At 04:28 PM 4/3/02 -0500, Kevin Old wrote:
>Hello all,
>
>I am a consultant brought in to manage and restructure some Perl scripts that
>were written some time ago. The programmer at that time was using the
>following code to do a query from within a CGI page.
>
> ${query} = "SELECT ccyymmddhh FROM inventory ORDER BY ccyymmddhh ;" ;
> open( INPUT, "echo \"${query}\" |
>/usr/local/mysql/bin/mysql -A -q -N gso|" ) ;
> @{ccyymmddhh} = ;
> chomp( @{ccyymmddhh} ) ;
> close( INPUT ) ;
*Shudder*
>I think that I should clean this up and reprogram this to use DBD::mysql
>rather than the way he does it here.
That's an understatement.
>Anyone have any idea if it would improve performance?
The only way to be sure is to try both ways, but... I would bet long odds
that the performance will be greatly improved. The above has to fire off a
subprocess and build up and tear down a connection for each query. If the
DBI way turns out to be slower, look me up at the Perl Conference and I'll
buy you a drink. So, I suspect, will Tim Bunce :-)
>I'd love to hear from people that have gone doing it this way to using DBI.
>
>Obviously I can run benchmarks before and after and see which takes longer,
>and I think that using DBI is not only much easier to read and manage, but
>probably a little faster. Just seeking the advice of others.
Go with easier to read and manage first. The above code is NOT capable of
being reused in obvious ways (suppose $query contained quote marks or shell
metacharacters).
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Core dump in plsql.t on Solaris
At 01:29 PM 5/18/01 -0400, Curt Russell Crandall wrote: >What compiler are you using? gcc 2.8.1. > If you are using Solaris cc, that might be >the problem. I've found that building Perl and it's modules with >something other than gcc leaves you open to pesky errors. Also, you did >run the perl Makefile.PL, right? Yep, several different ways as noted. > The only other thing I can think of is >that maybe you are compiling the module with a different compiler than the >perl interpreter was compiled with. Nope, I am totally scrupulous about that. I compiled perl from the same gcc a couple of days prior and it passed every test. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Core dump in plsql.t on Solaris
No matter what I have tried so far, I get a core dump in test 55 of plsql.t.
I'm on Solaris 2.5.1 with perl 5.6.1, DBI 1.15, and Oracle 7.2.2. I've
tried a plain make, and a make with the suggested -b, -c, -l, and -n
LIBCLNTSH, all result in:
t/plsql.dubious
Test returned status 0 (wstat 139, 0x8b)
test program seems to have generated a core
DIED. FAILED tests 55-63
Building with -g doesn't seem to help with gdb on the core:
Program terminated with signal 11, Segmentation fault.
"/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1": not in executable format:
File format not recognized.
#0 0xef554f04 in _end ()
Building with -p causes it to fail worse:
t/general...install_driver(Oracle) failed: Can't load
'blib/arch/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1:
/opt/perlnew/bin/perl: fatal: libclntsh.so.1.0: can't open file: errno=2 at
/opt/perlnew/lib/5.6.1/sun4-solaris-2.5.1/DynaLoader.pm line 206.
at (eval 1) line 3
Compilation failed in require at (eval 1) line 3.
Perhaps a required shared library or dll isn't installed where expected
The core dump happens at the last line of this part of plsql.t:
my $cur_query = q{
SELECT object_name, owner FROM all_objects
WHERE object_name LIKE :p1 and ROWNUM <= 3
};
my $cur1 = 42;
#$dbh->trace(4);
my $parent = $dbh->prepare(qq{
BEGIN OPEN :cur1 FOR $cur_query; END;
});
ok(0, $parent);
ok(0, $parent->bind_param(":p1", "V%"));
ok(0, $parent->bind_param_inout(":cur1", \$cur1, 0, { ora_type =>
ORA_RSET } ));
ok(0, $parent->execute());
BTW, I don't even understand that SQL, so maybe I can get by without it
working :-)
I've stepped through the test in the debugger and everything seems okay
until the call to _setup_handle:
696==> DBI::_setup_handle($h, $imp_class, $parent, $imp_data);
697
698:return $h unless wantarray;
699:($h, $i);
700 }
701 # minimum constructors for the tie's (alias to XS version)
702:sub DBI::st::TIEHASH { bless $_[1] => $_[0] };
At this point, a single step takes me to Carp::longmess with a @_ of
'SIGSEGV'. If instead I look at $h, I see this:
DB<3> x $h
0 DBI::st=HASH(0x5862dc)
SV = PVMG(0x586df8) at 0x587c40
REFCNT = 1
FLAGS = (ROK)
IV = 0
NV = 0
RV = 0x532dc4
dbih_getcom handle 'DBI::st=HASH(0x532dc4)' is not a DBI handle (has no
magic) at /opt/perlnew/lib/5.6.1/dumpvar.pl line 154.
SV = PVMG(0x586df8) at 0x587c40
REFCNT = 1
FLAGS = (ROK)
IV = 0
NV = 0
RV = 0x532dc4
SV = RV(0x3e1828) at 0xefffeed8
REFCNT = 1
FLAGS = (ROK,READONLY)
RV = 0x532dc4
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect() at /opt/perlnew/lib/5.6.1/perl5db.pl line 1483.
Debugged program terminated.
Well, that can't be right.
FWIW, I've been using these Oracle libraries successfully on Solaris 2.5.1
with perl 5.004_04 and a DBI of 0.89 and DBD::Oracle of 0.46 (don't laugh).
Any ideas? This is the only test that fails - well, I don't know what the
remaining 7 subtests would do, obviously.
Yeah, yeah, 7.2.2 is old. My next step is to essay 8.1.6 on Solaris
2.6. But I still need something working on Solaris 2.5.1, and Oracle 8.1.6
is not supported there.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
dbi: data source
Are there any data sources that don't begin with "dbi:"? If so, what? If not, are there any plans to make DBI work with some? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
