Re: Duplicate table structure
On 6/8/07, Peter Scott <[EMAIL PROTECTED]> wrote: 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. dbms_metadata has one nasty flaw - the output must be manually reformatted to be usable. Try using DDL::Oracle, as it does work. -- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist
Re: Typo in documentation
On Thu, Jun 07, 2007 at 03:38:48PM -0700, Evan Duffield wrote: > Was reading your documentation and found a typo. Thought you might like to > know. > > Due to the potentially high memory cost and unknown risks of loading in an > unknown number of drivers that just happen to be > installed on the system, this method is nor recommended for > general use. It is primarily intended as a quick way to see from > the command line what's installed. For example: I presume you mean the "is nor recommended". Thanks. That one got fixed a little while ago. Tim.
Error creating temporary tables using DBD::ODBC MSSQL
I all,
I white the script:
#!c:/Perl/bin/perl.exe
use DBI;
use DBD::ODBC;
$dbh = DBI->connect('dbi:ODBC:DSN', 'user', 'pwd');
#$str_sql1 = '
#declare @rownum int
#SELECT @rownum = (select count(*)
#from master..sysprocesses (nolock)
#where loginame in (\'tngusu\',\'tngprod\',\'uback\'))
#if @rownum > 0
# select @@Servername + \' NOK\' as conectividad_host
#else
# select @@Servername + \' OK\' as conectividad_host
# ';
$str_sql1 = '
declare @salida varchar(109)
declare @Stop varchar(40)
declare @Largo int
set @Stop = \'Prueba CheckServer\'
set @Largo = len(rtrim(@Stop))
create table ##Tabla
(
Resultado varchar(200)
)
insert into ##Tabla exec master..Svc_CICS \'SCCCECHO\',@Stop
select
case right(rtrim(Resultado),@Largo)
when @Stop then @@Servername + \' OK\'
else @@Servername + \' NOK\'
end as Conectividad_Host
from
##Tabla
drop table ##Tabla
';
$sql1 = $dbh->prepare($str_sql1);
$sql1->execute;
while ( @row = $sql1->fetchrow_array ) {
print "@row\n";
}
Now I got the error:
DBD::ODBC::db prepare failed: [Microsoft][ODBC SQL Server Driver][SQL
Server]Invalid object name '##Tabla'. (SQL-42S02)
[Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not
be prepared. (SQL-42000)(DBD: st_prepare/SQLPrepare err=-1) at
C:\Varios\scripts\Perl\DBI\UA\connect.pl line 44.
Can't call method "execute" on an undefined value at
C:\Varios\scripts\Perl\DBI\UA\connect.pl line 45.
When create a normal table it works just fine, but when try to create
a temporary table (#) it fail... I try putting the flag
odbc_exec_direct => 1 in the prepare statement but now the result
don't is empty
Any suggestions about it? or code optimizations for the sql statement?
Note: The commented sql code works fine...
Regards,
Hernan Dario A.
--
No matter how fast processors get,
software consistently finds new ways to eat up the extra speed
Typo in documentation
Was reading your documentation and found a typo. Thought you might like to know. Due to the potentially high memory cost and unknown risks of loading in an unknown number of drivers that just happen to be installed on the system, this method is nor recommended for general use. It is primarily intended as a quick way to see from the command line what's installed. For example:
Re: panic: DESTROY (dbih_clearcom) in trace output
On Fri, Jun 08, 2007 at 11:58:23AM +0100, Martin Evans wrote:
> Tim Bunce wrote:
> >On Thu, Jun 07, 2007 at 08:53:56PM +0100, Martin J. Evans wrote:
> >> (in cleanup) panic: DESTROY (dbih_clearcom) inner handle HASH is
> >> not a hash ref at
> >> /usr/lib/perl5/site_perl/5.8.8/DBIx/Log4perl/db.pm line 55.
> >
> >>I can find in the following in dbih_inner
> >>
> >> /* extra checks if being paranoid */
> >> if (DBIS->debug && (!SvROK(hrv) || SvTYPE(SvRV(hrv)) != SVt_PVHV)) {
> >>if (!what)
> >>return NULL;
> >>sv_dump(orv);
> >>croak("panic: %s inner handle %s is not a hash ref",
> >>what, neatsvpv(hrv,0));
> >> }
> >>
> >>but I'm not sure what it is croaking about. Is this something I need to
> >>worry about?
> >
> >Nope. Upgrade your DBI.
> >
> >This was fixed in r9395. The log comment was: "Remove old DBI internal
> >sanity check that's no longer valid (after spending a few hours banging
> >my head against it)"
>
> Thanks - that did the trick. Would you mind if I changed DBI::Changes to
> mention this in case others hit it?
Go ahead. Thanks.
Tim.
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/
Re: panic: DESTROY (dbih_clearcom) in trace output
Tim Bunce wrote:
On Thu, Jun 07, 2007 at 08:53:56PM +0100, Martin J. Evans wrote:
(in cleanup) panic: DESTROY (dbih_clearcom) inner handle HASH is not a
hash ref at /usr/lib/perl5/site_perl/5.8.8/DBIx/Log4perl/db.pm line 55.
I can find in the following in dbih_inner
/* extra checks if being paranoid */
if (DBIS->debug && (!SvROK(hrv) || SvTYPE(SvRV(hrv)) != SVt_PVHV)) {
if (!what)
return NULL;
sv_dump(orv);
croak("panic: %s inner handle %s is not a hash ref",
what, neatsvpv(hrv,0));
}
but I'm not sure what it is croaking about. Is this something I need to
worry about?
Nope. Upgrade your DBI.
This was fixed in r9395. The log comment was: "Remove old DBI internal
sanity check that's no longer valid (after spending a few hours banging
my head against it)"
Thanks - that did the trick. Would you mind if I changed DBI::Changes to
mention this in case others hit it?
Martin
