[16769] in Perl-Users-Digest
Perl-Users Digest, Issue: 4181 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 30 18:15:42 2000
Date: Wed, 30 Aug 2000 15:15:29 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <967673729-v9-i4181@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 30 Aug 2000 Volume: 9 Number: 4181
Today's topics:
Re: Is perl powerful enough to create cybermoney? (Steve Leibel)
Re: Is perl powerful enough to create cybermoney? (Craig Berry)
Re: Is perl powerful enough to create cybermoney? <lmoran@wtsg.com>
Re: Is perl powerful enough to create cybermoney? <Jonathan.L.Ericson@jpl.nasa.gov>
Re: Is perl powerful enough to create cybermoney? <lr@hpl.hp.com>
Re: Is perl powerful enough to create cybermoney? (Craig Berry)
Re: method="get" <flavell@mail.cern.ch>
Re: method="get" <timewarp@shentel.net>
Re: method="get" (brian d foy)
Re: method="get" (brian d foy)
Re: Need Help with CGI <gellyfish@gellyfish.com>
Re: Need Help with CGI <flavell@mail.cern.ch>
Re: output fun <russ.jones@rac.ray.com>
Parse::RecDescent, lookahead, and optional subrules. <ocschwar@mit.edu>
Re: Parsing a Excell table - or - a "Tab New_Line" text <bwalton@rochester.rr.com>
Re: Parsing a Excell table - or - a "Tab New_Line" text <bwalton@rochester.rr.com>
Re: Parsing a Excell table - or - a "Tab New_Line" text <info@digitaltango.com>
Re: Parsing a Excell table - or - a "Tab New_Line" text <jeff@vpservices.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 30 Aug 2000 12:50:16 -0700
From: stevel@bluetuna.com (Steve Leibel)
Subject: Re: Is perl powerful enough to create cybermoney?
Message-Id: <stevel-3008001250580001@192.168.100.2>
In article <sqoeham6c5d73@corp.supernews.com>, cberry@cinenet.net (Craig
Berry) wrote:
> pohanl@my-deja.com wrote:
> : The future of money.
>
> I hope said future involves more of it drifting my way. :)
>
> : As we move into the new century, the money system is being changed.
> : The value of currency is now being based on a subjective (demand
> : based) rather than an objective (backed by gold) basis.
>
> Actually, this has been practically true throughout the history of money
> (since the value of gold is itself subjective), and entirely true for the
> USA for most of the 20th century (since the gold standard was abandoned).
>
> : Before, when the government prints new money, they hold the same value
> : in gold in a vault somewhere.
>
> Again, this system has not been in effect for quite a long time, in any of
> the "developed" countries.
>
> : Now, the government prints new money when inflation rate is low or loan
> : interest rate is high.
>
> This is called "monetary policy", and it's been around quite a while, too.
>
> : The banks make money from the difference in interest rates on the loan
> : (you pay higher interest, and they collect the difference between
> : your rate and the rate they pay to the government).
>
> And of course take a higher risk that you will default.
>
> [snip]
> : But have you noticed something? In the same case as the government
> : making cash out of thin air, the companies are creating cash out of
> : thin air.
>
> Well, yes, in a sense. What is really being done is the creation of
> capital (tangible value) out of "thin air" (the more efficient combination
> and utilization of existing resources). This is what drives per-capita
> economic expansion. More money is then placed in circulation to prevent
> deflationary pressures.
>
> : The government prints new money (ANY amount they want).
> : Likewise, the companies creates stocks (ANY amount they want).
>
> Well, not quite. Their are SEC limitations, exchange rules, and of course
> if the numbers don't work out reasonably nobody will purchase the stock.
>
> : Whereas the banks purchase the new money (as a loan), the public
> : at large is purchasing the stocks (not a loan).
>
> Stocks are a quasi-loan, in important ways.
Stocks are in no way a loan. Stocks represent equity, or ownership.
Apologies for perpetuating this off-topic thread, but the difference
between equity and debt is so fundamental that I would not want anyone to
be confused by what this poster wrote.
Steve L
------------------------------
Date: Wed, 30 Aug 2000 19:58:34 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Is perl powerful enough to create cybermoney?
Message-Id: <sqqprauhc5d13@corp.supernews.com>
Steve Leibel (stevel@bluetuna.com) wrote:
: > : Whereas the banks purchase the new money (as a loan), the public
: > : at large is purchasing the stocks (not a loan).
: >
: > Stocks are a quasi-loan, in important ways.
:
: Stocks are in no way a loan. Stocks represent equity, or ownership.
: Apologies for perpetuating this off-topic thread, but the difference
: between equity and debt is so fundamental that I would not want anyone to
: be confused by what this poster wrote.
Note my 'quasi' and 'in important ways' weaseling. Yes, stocks represent
equity, but the majority of stock is non-voting, or held in small enough
quantities to make all aspects of ownership other than claim on a share of
revenues irrelevant. Thus, mechanically, a stock purchase is quite
similar to a loan, in that it is an exchange of present value for
(hopefully) greater future value, from the buyer's side of the equation,
and a path to short-term liquidity from the seller's side.
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Every force evolves a form."
| - Shriekback
------------------------------
Date: Wed, 30 Aug 2000 16:59:33 -0400
From: Lou Moran <lmoran@wtsg.com>
Subject: Re: Is perl powerful enough to create cybermoney?
Message-Id: <pusqqsg3vkdjf0gbecesmrk0r7jknt1quc@4ax.com>
On Tue, 29 Aug 2000 07:04:51 GMT, pohanl@my-deja.com wrote:
{SNIP}
#!/usr/bin/perl -w
use strict;
my $insanemoneypostramblings= 0;
if ($insanemoneypostramblings eq '0') {
print "Why did you post this?"
}
Registered Linux user number 187055
------------------------------
Date: Wed, 30 Aug 2000 13:07:30 -0700
From: Jon Ericson <Jonathan.L.Ericson@jpl.nasa.gov>
Subject: Re: Is perl powerful enough to create cybermoney?
Message-Id: <39AD6982.45A3A99D@jpl.nasa.gov>
pohanl@my-deja.com wrote:
[No perl content except:]
> Subject: Is perl powerful enough to create cybermoney?
I want to know if a cybermonkey is powerful enough to create perl. Oh,
wait ... I misread the question. Perl is a tool. _People_ use it to
create things.
Jon
--
Knowledge is that which remains when what is
learned is forgotten. - Mr. King
------------------------------
Date: Wed, 30 Aug 2000 14:31:12 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Is perl powerful enough to create cybermoney?
Message-Id: <MPG.14171cff7252af298ad06@nntp.hpl.hp.com>
In article <pusqqsg3vkdjf0gbecesmrk0r7jknt1quc@4ax.com> on Wed, 30 Aug
2000 16:59:33 -0400, Lou Moran <lmoran@wtsg.com> says...
> On Tue, 29 Aug 2000 07:04:51 GMT, pohanl@my-deja.com wrote:
>
> {SNIP}
>
> #!/usr/bin/perl -w
> use strict;
>
> my $insanemoneypostramblings= 0;
>
> if ($insanemoneypostramblings eq '0') {
> print "Why did you post this?"
> }
I wouldn't switch from number to string.
if ($insanemoneypostramblings == 0) {
print "Why did you post this?"
}
Or, simply,
unless ($insanemoneypostramblings) {
print "Why did you post this?"
}
Or, sans punctuation:
print "Why did you post this?" unless $insanemoneypostramblings;
But $insanemoneypostramblings should be 'true', shouldn't it? So the
tests should be reversed.
Thanks for injecting even a bit of Perl into this thread. :-)
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Wed, 30 Aug 2000 21:52:49 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Is perl powerful enough to create cybermoney?
Message-Id: <sqr0hhhbc5d184@corp.supernews.com>
Jon Ericson (Jonathan.L.Ericson@jpl.nasa.gov) wrote:
: pohanl@my-deja.com wrote:
: [No perl content except:]
: > Subject: Is perl powerful enough to create cybermoney?
:
: I want to know if a cybermonkey is powerful enough to create perl. Oh,
: wait ... I misread the question. Perl is a tool. _People_ use it to
: create things.
Yeah, but tool strength is important. Try building a house with
foam-rubber hammers some time. :)
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Every force evolves a form."
| - Shriekback
------------------------------
Date: Wed, 30 Aug 2000 20:12:27 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: method="get"
Message-Id: <Pine.GHP.4.21.0008302010320.12815-100000@hpplus03.cern.ch>
On Wed, 30 Aug 2000, brian d foy wrote:
> > Don't overlook CGI.pm's use of autoloading.
>
> self-loading, that is. all of that data is still in the module
> rather than in separate files for each function.
Thanks for the correction! I suppose I really meant to say
load-on-demand, or would that be misleading too?
cheers
------------------------------
Date: Wed, 30 Aug 2000 15:42:28 -0400
From: Albert Dewey <timewarp@shentel.net>
Subject: Re: method="get"
Message-Id: <39AD63A4.4F23A5E7@shentel.net>
brian d foy wrote:
>
> if you don't like all of the CGI.pm cruft, there are lighter CGI
> parsers available from CPAN.
>
> --
> brian d foy
> CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
> Perl Mongers <URL:http://www.perl.org/>
Well, the one great feature of CGI.pm is that lightness is not an issue because it is
optimized to load only the parts relevant to your needs when you use it and not the whole
bloody mess. This is why I go ahead and use it over other parsers. This is according to the
book written by Lincoln Stein on CGI.pm so I take his word for this and happily go about my
business.
Albert Dewey
--
@i = ('a' .. 'z', 'A' .. 'Z', ' ');
print "$i[35]$i[20]$i[18]$i[19]$i[52]$i[26]$i[13]$i[14]";
print "$i[19]$i[7]$i[4]$i[17]$i[52]$i[41]$i[4]$i[17]";
print "$i[11]$i[52]$i[33]$i[0]$i[2]$i[10]$i[4]$i[17]";
------------------------------
Date: Wed, 30 Aug 2000 16:14:43 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: method="get"
Message-Id: <brian-ya02408000R3008001614430001@news.panix.com>
In article <Pine.GHP.4.21.0008302010320.12815-100000@hpplus03.cern.ch>, "Alan J. Flavell" <flavell@mail.cern.ch> posted:
> On Wed, 30 Aug 2000, brian d foy wrote:
>
> > > Don't overlook CGI.pm's use of autoloading.
> > self-loading, that is. all of that data is still in the module
> > rather than in separate files for each function.
> Thanks for the correction! I suppose I really meant to say
> load-on-demand, or would that be misleading too?
well, with self-loading, everything is in the module file, rather
that split out into separate files as with autoload. they both
make functions available on demand. i personally don't like the
way CGI.pm does this which is one of the reasons i hesitate to
use it.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: Wed, 30 Aug 2000 16:17:29 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: method="get"
Message-Id: <brian-ya02408000R3008001617290001@news.panix.com>
In article <39AD63A4.4F23A5E7@shentel.net>, Albert Dewey <timewarp@shentel.net> posted:
> brian d foy wrote:
> > if you don't like all of the CGI.pm cruft, there are lighter CGI
> > parsers available from CPAN.
> Well, the one great feature of CGI.pm is that lightness is not an issue because ...
maybe you just haven't work on big enough systems to care about
the difference. if all you need are the parser features, then why
not use a CGI module that only supplies those? CGI.pm is overkill
unless you are going to use a significant portion of its
non-parser-related feature set.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: 29 Aug 2000 21:53:07 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Need Help with CGI
Message-Id: <8oh7rj$r3c$1@orpheus.gellyfish.com>
On Tue, 29 Aug 2000 04:46:39 GMT jason wrote:
> Tuxman <s1sims@home.com> wrote ..
>>Content-Type: text/html; charset=us-ascii
>>
>><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
>
> *plonk*
>
I'm with you matey - I would even stick my neck out to suggest that the
doctype lies about the actual content of the document ....
/J\
--
yapc::Europe in assocation with the Institute Of Contemporary Arts
<http://www.yapc.org/Europe/> <http://www.ica.org.uk>
------------------------------
Date: Wed, 30 Aug 2000 22:47:26 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Need Help with CGI
Message-Id: <Pine.GHP.4.21.0008302241240.12815-100000@hpplus03.cern.ch>
On 29 Aug 2000, Jonathan Stowe wrote:
> >><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> >
> > *plonk*
>
> I'm with you matey - I would even stick my neck out to suggest that the
> doctype lies about the actual content of the document ....
^^^^^^^^^^^^
Worse than that: the doctype is meaningless, because certain
case-sensitive parts (OK, I'll be honest, I forget which parts, and
it's OT anyway) that have to be in uppercase, aren't.
If you utter something meaningless, can it be a lie? That spoof is, I
guess, injected by A Certain Software Package in order to lend a
spurious aroma of technical wizardry to the product. YMMV.
------------------------------
Date: Wed, 30 Aug 2000 16:30:02 -0500
From: Russ Jones <russ.jones@rac.ray.com>
Subject: Re: output fun
Message-Id: <39AD7CDA.E9FD71A0@rac.ray.com>
ankban4@my-deja.com wrote:
>
> HI
> Without using the formatting features , how do i print an output like
> this . i tried but my code is too huge and ugly.
>
> ABCDEFGFEDCBA
> ABCDEF FEDCBA
> ABCDE EDCBA
> ABCD DCBA
> ABC CBA
> AB BA
> A A
>
Being a terminal insomniac, I came up with the idea to do this at about
four this morning.
I took all of the responses to this question (the ones that actually
worked, anyway) and put them all in one executable and then benchmarked
them. Here's the code:
#!/opt/perl5/bin/perl -w
use strict;
use Benchmark qw(timethese);
timethese ( 1000,
{
tom => q{
# my $str = shift || 'ABCDEFGFEDCBA';
my $str = 'ABCDEFGFEDCBA';
my $len = length($str);
my $off = int($len / 2);
for (my $i=1; $i<=$len; $i+=2) {
print "$str\n";
substr($str,$off--,$i,' ' x $i);
}
},
uri => q{
$_="ABCDEFGFEDCBA\n";print;print while y/G/ /||s/.( +)\S/ $1 /g;
},
larry => q{
$_="ABCDEFGFEDCBA\n";do{print}while y/G/ /||s/.( +)\S/ $1 /g;
},
keith => q{
$_="ABCDEFGFEDCBA\n";print;print while s/G|(?<= )\w|\w(?= )/ /g;
},
keith2 => q{
$_="ABCDEFGFEDCBA\n";print,s/G|(?<= ).|.(?= )/ /g while/\S/;
},
greg => q{
my $letters = "ABCDEFG";
my $out = $letters . reverse $letters;
$out =~ tr/A-Z//s;
for (split //, reverse $letters) {
print $out, "\n";
eval "\$out =~ tr/$_/ /";
}
},
yanick => q{
local $\ = "\n";
$_ = "ABCDEFGFEDCAB";
print and s#.( +).# $1 #g or substr($_,length()/2,1)=' ' while /\w/;
},
russ => q{
print <<EOT;
ABCDEFGFEDCBA
ABCDEF FEDCBA
ABCDE EDCBA
ABCD DCBA
ABC CBA
AB BA
A A
EOT
},
});
exit(0);
Tom and Yanick's routines were both coded to work like a subroutine, I
took the liberty of hard-coding the initial string. Tom's in particular
acted in a very interesting manner if you use his original code.
Uncomment the commented line, and comment out the one after it.
I had to go through some crapola to get to the Benchmark results. I
redirected STDOUT to a file, then sorted it so I could isolate the stats
from Benchmark. Also, the final results are cut and paste, EXCEPT I
changed the words "wallclock secs" to wsecs to avoid some ugly word
wrap.
And here's my results:
tom: 3 wsecs ( 2.12 usr + 0.03 sys = 2.15 CPU) @ 4651.16/s
(n=10000)
uri: 4 wsecs ( 4.25 usr + 0.03 sys = 4.28 CPU) @ 2336.45/s
(n=10000)
greg: 21 wsecs (20.07 usr + 0.04 sys = 20.11 CPU) @ 497.27/s
(n=10000)
russ: 0 wsecs ( 0.06 usr + 0.02 sys = 0.08 CPU) @ 125000.00/s
(n=10000)
keith: 6 wsecs ( 5.15 usr + 0.03 sys = 5.18 CPU) @ 1930.50/s
(n=10000)
larry: 5 wsecs ( 4.26 usr + 0.04 sys = 4.30 CPU) @ 2325.58/s
(n=10000)
keith2: 6 wsecs ( 6.12 usr + 0.03 sys = 6.15 CPU) @ 1626.02/s
(n=10000)
yanick: 4 wsecs ( 3.91 usr + 0.02 sys = 3.93 CPU) @ 2544.53/s
(n=10000)
My own blisteringly fast routine, "russ," is just in there as an
example. Sometimes a hammer IS the right tool.
--
Russ Jones - HP OpenView IT/Operatons support
Raytheon Aircraft Company, Wichita KS
russ_jones@rac.ray.com 316-676-0747
print <<JAPH;
Just another Perl honker,
JAPH
------------------------------
Date: Wed, 30 Aug 2000 17:46:20 -0400
From: Omri Schwarz <ocschwar@mit.edu>
Subject: Parse::RecDescent, lookahead, and optional subrules.
Message-Id: <39AD80AC.5D01CC39@mit.edu>
What is the proper way to do
foo : bar (...baz)(?)
{
if ("we find a baz") {
do one thing;
} else
do another;
}
}
------------------------------
Date: Wed, 30 Aug 2000 18:11:04 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Parsing a Excell table - or - a "Tab New_Line" text file?
Message-Id: <39AD4E5F.7B1AB660@rochester.rr.com>
Etienne Laverdiere wrote:
...
> But I have notice that my parsing cannot read a field containing more than
> 255 characters.
> I have a "description" field that usualy contain more than 255 characters.
> Where could I set the "retreiving field type"?
> I would need to set something like "textsize=10000", or VarChar(10000) or
> "memo"... when I am reading my Excel table.
>
> I know that I can specify the DataType in a Bind Value
> (Mastering DBI, p.124 : $sth->bind_param(3, 123, {TYPE+> SQL_VARCHAR});)
>
> VBy default, everything seems to be a VarChar in DBI. I don't know where to
> specify my Select values.
...
> Etienne Laverdiere
> Montreal
...
You need to set LongReadLen on your DBI handle to a larger value.
Something like:
$dbh->{LongReadLen}=10000;
after you have opened the database, for example. It should work then.
Looking in:
perldoc DBI
for additional info.
I note one other slight piece of weirdness: the type of a field is
apparently defined by the type of data in the entry on the second line
of the range. Mixed numbers and text in a given column don't work.
While that is certainly consistent with database behavior, I was a bit
surprised to see it in Excel. That certainly makes the DBI technique a
less appealing method of accessing spreadsheets (as compared to OLE).
--
Bob Walton
------------------------------
Date: Wed, 30 Aug 2000 18:56:16 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Parsing a Excell table - or - a "Tab New_Line" text file?
Message-Id: <39AD58FA.F55DF461@rochester.rr.com>
[warning: mostly off-topic]
Bart Lateur wrote:
>
> Bob Walton wrote:
>
> >I also note that one can instead specify a worksheet as follows:
> >
> > my $table='[Sheet1$]';
> >
> >to replace
> >
> > my $table='table1';
> >
> >The square brackets and the $ are required, and "Sheet1" must be the
> >name of a sheet in the workbook.
>
> Any idea on how you can get the count of worksheets out of a file, as
> well as the names? Otherwise, you cannot possibly write very generic
> data extraction code, can you?
>
I think you'll have to use OLE for that (with OLE, you can [from Perl]
do anything to or with a spreadsheet that you can do with Excel
macros). Something like:
use Win32::OLE;
# use already-running instance of Excel
eval {$ex = Win32::OLE->GetActiveObject('Excel.Application')};
die "Excel not installed" if $@;
die "Excel not running" unless defined $ex;
$wsc=$ex->Worksheets->Count;
print "There are $wsc worksheets\n";
> Also, getting the size of a worksheet, rows x columns, would be
> interesting.
Same first 5 lines as above plus (assuming you want the first
worksheet):
$rowc=$ex->Worksheets(1)->UsedRange->Rows->Count;
$columnc=$ex->Worksheets(1)->UsedRange->Columns->Count;
print "worksheet is ${rowc}x$columnc\n";
Note that the above will return the size of the smallest rectangle of
cells that contains all the cells that contain something (non-blank in
Excel-speak, even though that makes a cell containing a blank
non-blank). It is not necessarily the row number of the cell with the
largest row number and the column number of the cell with the largest
column number (only if row 1 and column 1 contain something). Note that
you could also use DBI to get the same info, by looking at the array
sizes in the array-of-arrays reference returned by selectall_arrayref.
> It's not necessary for every single developer to rediscover this info by
> themselves. Somebody should collect all these instructions and put them
> in some (web) page or a FAQ.
That might be a good idea. On the other hand, the Micro$loth stuff has
so much version churn that it would be a real chore to keep it up. And
most of it is really Excel or OLE stuff, not Perl stuff, anyway, so it
should probably belong elsewhere. Maybe there is a FAQ on some Excel
group somewhere?? (I despise Excel, and interface with it only because
sometimes I can't get out of it, so I don't even know if there are such
groups). Excel's object browser gives some hints if you have a clue of
where to start (if you don't have a clue where to start, it is a
daunting task to discover even the simplest stuff).
...
> Bart.
--
Bob Walton
------------------------------
Date: Wed, 30 Aug 2000 19:50:36 GMT
From: "Etienne Laverdiere" <info@digitaltango.com>
Subject: Re: Parsing a Excell table - or - a "Tab New_Line" text file?
Message-Id: <gAdr5.221010$1h3.3828291@news20.bellglobal.com>
Yes you are right. I have the same problem now.
"Mixed numbers and text in a given column don't work.!"
I must find a way to import any data of any type, like reading for all field
'type=>text' for a number or a real text.
I will continue searching. If you have a solution don't hesitate to write it
here.
Best Regards,
Etienne Laverdiere
Montreal
"Bob Walton" <bwalton@rochester.rr.com> wrote in message
news:39AD4E5F.7B1AB660@rochester.rr.com...
> Etienne Laverdiere wrote:
> ...
> > But I have notice that my parsing cannot read a field containing more
than
> > 255 characters.
> > I have a "description" field that usualy contain more than 255
characters.
> > Where could I set the "retreiving field type"?
> > I would need to set something like "textsize=10000", or VarChar(10000)
or
> > "memo"... when I am reading my Excel table.
> >
> > I know that I can specify the DataType in a Bind Value
> > (Mastering DBI, p.124 : $sth->bind_param(3, 123, {TYPE+> SQL_VARCHAR});)
> >
> > VBy default, everything seems to be a VarChar in DBI. I don't know where
to
> > specify my Select values.
> ...
> > Etienne Laverdiere
> > Montreal
> ...
> You need to set LongReadLen on your DBI handle to a larger value.
> Something like:
>
> $dbh->{LongReadLen}=10000;
>
> after you have opened the database, for example. It should work then.
> Looking in:
>
> perldoc DBI
>
> for additional info.
>
> I note one other slight piece of weirdness: the type of a field is
> apparently defined by the type of data in the entry on the second line
> of the range. Mixed numbers and text in a given column don't work.
> While that is certainly consistent with database behavior, I was a bit
> surprised to see it in Excel. That certainly makes the DBI technique a
> less appealing method of accessing spreadsheets (as compared to OLE).
> --
> Bob Walton
------------------------------
Date: Wed, 30 Aug 2000 13:09:06 -0700
From: Jeff Zucker <jeff@vpservices.com>
To: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Parsing a Excell table - or - a "Tab New_Line" text file?
Message-Id: <39AD69E2.68F3F8EB@vpservices.com>
Bob Walton wrote:
>
> I note one other slight piece of weirdness: the type of a field is
> apparently defined by the type of data in the entry on the second line
> of the range. Mixed numbers and text in a given column don't work.
That is the default behaviour (or actually the first 8 rows), but it is
configurable. You can have Excel determine the data type based on a
user definable number of rows. From the ODBC driver help documents
(included with ODBC drivers as part of windoze):
<quote>
Rows to Scan:
The number of rows to scan to determine the data type of each column.
The data type is determined given the maximum number of kinds of data
found. If data is encountered that does not match the data type guessed
for the column, the data type will be returned as a NULL value.
For the Microsoft Excel driver, you may enter a number from 1 to 16 for
the rows to scan. The value defaults to 8; if it is set to 0, all rows
are scanned. (A number outside the limit will return an error.)
For the Text driver, you may enter a number from 1 to 32767 for the
number of rows to scan; however, the value will always default to 25. (A
number outside the limit will return an error.)
To set this option dynamically, use the MAXSCANROWS keyword in a call to
SQLConfigDataSource.
</quote>
> That certainly makes the DBI technique a less appealing method of
> accessing spreadsheets (as compared to OLE).
While I am no fan of M$, I think you may be a bit premature in your
assessment. ODBC is one of their more complete implementations and it is
richer than it appears at first glance.
--
Jeff
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 4181
**************************************
