Re: DBD::Oracle and Oracle 8 AGAIN
That is a good question. I have had many complaints about this over the past year. I think it is about time someone-most likely me- post some .pps for older other clients. Not promising anything but I will see what I can do. For the present I would run through the Readme.win32.txt one more time it realy only requires a good deal of time to do the the downloads and then a few mins to actually do the compile and install no knolege of C or even programming is required just follow the docs. Cheers John Scoles [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I'm trying to let DBD::Oracle connect to Oracle DB 8.0.x. My client OS is Windows XP, ActivePerl 588. From lists entitiled DBD::Oracle and Oracle 8 and other articles I found the current DBD-Oracle.ppd in ActiveStates.com uses Oracle10g, which cann't connct to older DBs less than R8.1.7.4. The step to make DBD::Oracle in the doc README.win32.txt is too hard to me, and I think many people are still in trouble. Is there older DBD-Oracle.ppd for AP58x to connect to DB 8.0.x. ? Regards, [EMAIL PROTECTED]
Re: AutoCommit and DBI::Proxy driver
Hi Tim, Sorry it's been a while, I was on holiday. Tim Bunce [EMAIL PROTECTED] wrote on 26/09/2006 23:36:06: Can you try the version in the svn repository. For how, see http://search.cpan.org/~timb/DBI-1.52/DBI.pm#CONTRIBUTING Let me know how it goes. I can confirm that AutoCommit now switches on and off correctly, so multiple transactions (begin_work/commits) now work as expected. Also, please setup a little test script that uses selectall_arrayref to fetch from the server. Time how long it takes with a select that fetches, say, a few thousand rows. Then add this like to the code: sub DBD::Proxy::db::selectall_arrayref; are time it again. I tried that but when I added the sub, $dbh-selectall_arrayref returned an undef value (quite quickly: 0.26769s vs 8.144393s without). I had RaiseError on but no error was reported. As a side issue, I started to wonder how large result sets would get on with RPC::PlServer's maxmessage option, since I assume the intention is to return the results in 1 message. (maxmessage defaults to 64K, but the pod doesn't mention if you can disable it completely -- I've been bitten by it before). Thanks! Tim. No, my thanks to you :-) best regards, John.
Trouble installing DBI without using ActiveState Repository
My company is including the installation of the DBD-Oracle and DBI Perl packages as part of the next scheduled release of our software, which is bundled with ActivePerl 5.8.3. We need to be able to install our software on machines that do *not* have internet access, and as part of the install I have a DOS batch file that turns off searching the ActiveState Repository: call %1\ppm3.bat rep add xycd %2 call %1\ppm3.bat rep off ActiveState PPM2 Repository call %1\ppm3.bat rep off ActiveState Package Repository for %%f in (*.ppd) do call %1\ppm3.bat install %%f %1\%%f.log 21 call %1\ppm3.bat rep on ActiveState PPM2 Repository call %1\ppm3.bat rep on ActiveState Package Repository call %1\ppm3.bat rep delete xycd However, I then get an error during the install of DBI that Package 'Test-Simple' not found; use 'Search' first. I find this puzzling as version .47 of Test-Simple that is installed as part of the 5.8.3 installation, and the DBI.ppd file is (if I'm understanding this correctly) version .4 or greater: DEPENDENCY NAME=Test-Simple VERSION=0,4,0,0 / Has anyone else run into this? Do I need to install a different version of Test-Simple?
Re: Trouble installing DBI without using ActiveState Repository
Have you run 'ppm describe Test-Simple' to confirm that that is what you actually have (or perl -MTest::Simple -e print $Test::Simple::VERSION )? I can't confirm on my laptop that Test-Simple was put in before or together with DBI, but this is a way you can confirm that it's actually on yours. Jeff On 10/4/06, Lisa Goldsmith [EMAIL PROTECTED] wrote: My company is including the installation of the DBD-Oracle and DBI Perl packages as part of the next scheduled release of our software, which is bundled with ActivePerl 5.8.3. We need to be able to install our software on machines that do *not* have internet access, and as part of the install I have a DOS batch file that turns off searching the ActiveState Repository: call %1\ppm3.bat rep add xycd %2 call %1\ppm3.bat rep off ActiveState PPM2 Repository call %1\ppm3.bat rep off ActiveState Package Repository for %%f in (*.ppd) do call %1\ppm3.bat install %%f %1\%%f.log 21 call %1\ppm3.bat rep on ActiveState PPM2 Repository call %1\ppm3.bat rep on ActiveState Package Repository call %1\ppm3.bat rep delete xycd However, I then get an error during the install of DBI that Package 'Test-Simple' not found; use 'Search' first. I find this puzzling as version .47 of Test-Simple that is installed as part of the 5.8.3 installation, and the DBI.ppd file is (if I'm understanding this correctly) version .4 or greater: DEPENDENCY NAME=Test-Simple VERSION=0,4,0,0 / Has anyone else run into this? Do I need to install a different version of Test-Simple? -- -- The darkest places in hell are reserved for those who maintain their neutrality in times of moral crisis. Dante Alighieri (1265 - 1321) They who would give up an essential liberty for temporary security, deserve neither liberty or security. Benjamin Franklin Our lives begin to end the day we become silent about things that matter. Martin Luther King The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. Amendment IV to the Constitution of the United States --
When is a string a number?
Hi, I'm hoping someone here can give me some insight in to what I can do as I feel sure someone must have hit this problem before. The software I'm working is a good deal more complex than what is described here but I've tried to resolve it down to make it more simple (perhaps unsuccessfully). The application reads values from a databases (but we'll stick to Oracle for now), converts the data to JSON (JavaScript Object Notation), writes the json to a file where it is picked up by some javascript code. JSON was chosen because JSON is native to javascript and the javascript can simply eval the read data to turn it into a javascript object. With DBI/DBD::Oracle all values read from the database are scalars. As everyone will know, whether something read from the database is a string or a number in Perl purely depends on the context it is used in so: $a = 1; print $a +1 results in 2 and print $a . 2 results in 12; The problem is javascript is more tightly typed than Perl and it matters whether something is a number or a string - it affects what operations you can perform on a variable. In JSON, a string is represented by quotes around it and a number is missing the quotes. My problem is that values read from the database which are actually numbers (in the database) look like strings to the JSON parser so when I do a selectall_arrayref(select number_field from table) and convert the result to JSON I get: [12] in the serialised JSON data instead of: [12] I have to admit I don't know how the JSON module knows what is a number and what is a string in Perl but I see the same issue with Data::Dumper so I presume there must be some way to find out if a perl scalar is a number or a string. The problem gets a lot worse for me since I do some arithmetic on values pulled from the database before converting them to JSON and this is where Perl seems to change them into numbers e.g. $r = selectall_arrayref(select number1, number2 from table); $r-[0] += 2; results in JSON output of: [3, 3] and this really annoys javascript since the first value is typed as a number and the second as a string. You can imagine this can get really hairy if you have a field in the DB called house_number_or_name. Whilst investigating this I tried to reproduce with Data::Dumper (another data serialiser) but the problem gets even more unfathomable to me: perl -MData::Dumper -le '$a = [1,2];print Dumper($a);' $VAR1 = [1,'2']; so Data::Dumper knows 2 is a string (XS version) and yet: perl -MData::Dumper -le ' $Data::Dumper::Useperl =1;$a = [1,2];print Dumper($a);' $VAR1 = [1,2]; just because I've switched to a Perl version of Data::Dumper 2 is a number. I don't want to have to do ($var +0) on all the number fields I pull from the database (to turn them into numbers) and neither do I want to do a '$var .= ' (to turn all the fields into strings). As an aside (and probably a perl question rather than a DBI one) does anyone know why the type of a scalar changes when you use it on the right side of an assignment: perl -MData::Dumper -le '$a=1; print Dumper($a); $b += $a; print Dumper($a);' $VAR1 = '1'; $VAR1 = 1; How does JSON and Data::Dumper know whether Perl thinks something is a number or a string? Sorry for the long posting. As I said, someone must have hit this before and I hope you can offer me some insight as I'm rather stuck with this now. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
swap_inner_handle
I have an issue with proper usage of swap_inner_handle: Say I have a dbh with an active sth. I create a new dbh (new_dbh) and swap its inner handle with dbh. Now is sth a child of dbh or new_dbh? i.e., is sth linked to the inner dbh, or not at all? Then I create a new sth (new_sth) and swap its inner handle with sth. What happens? Thanks, H
Re: When is a string a number?
On 10/4/06, Martin J. Evans [EMAIL PROTECTED] wrote: With DBI/DBD::Oracle all values read from the database are scalars. As everyone will know, whether something read from the database is a string or a number in Perl purely depends on the context it is used in so: internally, there are flags in the SV structure that hint as to what conversions have been done on the SV already, for efficiency's sake. I have to admit I don't know how the JSON module knows what is a number and what is a string in Perl but I see the same issue with Data::Dumper so I presume there must be some way to find out if a perl scalar is a number or a string. It seems like the pure perl Dumper tests values with a regex and optimizes to numbers when the stringification matches a number template, while the XS version checks the flags in the SV structure. The problem gets a lot worse for me since I do some arithmetic on values pulled from the database before converting them to JSON and this is where Perl seems to change them into numbers e.g. I don't want to have to do ($var +0) on all the number fields I pull from the database (to turn them into numbers) and neither do I want to do a '$var .= ' (to turn all the fields into strings). you might have to do exactly that. $var will produce a string version. Sorry. Apparently you can tell the JSON module to make everything strings: http://search.cpan.org/~makamaka/JSON-1.07/lib/JSON.pm#AUTOCONVERT As an aside (and probably a perl question rather than a DBI one) does anyone know why the type of a scalar changes when you use it on the right side of an assignment: perl -MData::Dumper -le '$a=1; print Dumper($a); $b += $a; print Dumper($a);' $VAR1 = '1'; $VAR1 = 1; The has-been-evaluated-as-a-number flag got set on $a when it was evaluated as a number; then Dumper, with both available, chose the number format. How does JSON and Data::Dumper know whether Perl thinks something is a number or a string? inspecting the flags; except pure-perl Dumper apparently uses a regular expression to identify numbers. Those are guesses. The source is available for your inspection. -- The Country Of The Blind, by H.G. Wells http://cronos.advenge.com/pc/Wells/p528.html
Re: When is a string a number?
On Wed, 2006-10-04 at 14:00 -0500, David Nicol wrote: On 10/4/06, Martin J. Evans [EMAIL PROTECTED] wrote: With DBI/DBD::Oracle all values read from the database are scalars. As everyone will know, whether something read from the database is a string or a number in Perl purely depends on the context it is used in so: internally, there are flags in the SV structure that hint as to what conversions have been done on the SV already, for efficiency's sake. As I suspected. I have to admit I don't know how the JSON module knows what is a number and what is a string in Perl but I see the same issue with Data::Dumper so I presume there must be some way to find out if a perl scalar is a number or a string. It seems like the pure perl Dumper tests values with a regex and optimizes to numbers when the stringification matches a number template, while the XS version checks the flags in the SV structure. OK, I only introduced the Data::Dumper example as it seemed very similar but read on - I over simplified a little. However, it seems strange to me that the pure perl Data::Dumper does something different. If I was using Data::Dumper for data interchange and switched from the pure perl to the XS version (or vice versa) and then called another XS based module with the results - they could be different. The problem gets a lot worse for me since I do some arithmetic on values pulled from the database before converting them to JSON and this is where Perl seems to change them into numbers e.g. I don't want to have to do ($var +0) on all the number fields I pull from the database (to turn them into numbers) and neither do I want to do a '$var .= ' (to turn all the fields into strings). you might have to do exactly that. $var will produce a string version. Sorry. This seems amazing - I really did not want to do this. I guess what I'm saying is that it would be really useful for a DBD to mark a number as a number so it does not start as a string and mutate to a number when I do arithmetic on it. Most DBDs must know if the column is a number one or not (certainly DBD::ODBC does). Apparently you can tell the JSON module to make everything strings: http://search.cpan.org/~makamaka/JSON-1.07/lib/JSON.pm#AUTOCONVERT Here was an over simplification. I moved from JSON to JSON Syck. The JSON module is a purl perl module and does the right thing for me for all the cases I tried but I changed to JSON Syck which uses the libsyck library for speed. This explains the difference since JSON Syck is XS and will know the flags in the SV structure and JSON won't. As an aside (and probably a perl question rather than a DBI one) does anyone know why the type of a scalar changes when you use it on the right side of an assignment: perl -MData::Dumper -le '$a=1; print Dumper($a); $b += $a; print Dumper($a);' $VAR1 = '1'; $VAR1 = 1; The has-been-evaluated-as-a-number flag got set on $a when it was evaluated as a number; then Dumper, with both available, chose the number format. That's interesting to know, I'll look into that. I was rather surprised the right hand side of an evaluation changed the type of a variable on the right hand side. How does JSON and Data::Dumper know whether Perl thinks something is a number or a string? inspecting the flags; except pure-perl Dumper apparently uses a regular expression to identify numbers. Those are guesses. The source is available for your inspection. I did look at it briefly but not extensively since it was not my primary problem. Thanks for your insights David, they have increased my understanding although I still feel stuck. I could move back to using the JSON module but I could run into problems with fields like house_name_or_number which I'm now guessing JSON will serialise as a number when it looks like a number and a string when not. If I stick with JSON Syck (which is a lot faster and I need the speed), I'm forced to do +0 on all database fields I know are a number and I don't like this at all. I guess I'm rather surprised to hit this issue without seeing anyone else with it after all this time using DBI. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
RE: When is a string a number?
This is a very interesting problem, Martin, because most of us ordinary Perl users don't experience these issues on a regular basis if ever. Just one thought, maybe a bit naiive, but wouldn't it be possible to copy all the values you've got from the database and do the extra computations on the copies separately? It might avoid polluting the originals before passing them off to JSON. -Will -Original Message- From: Martin J. Evans [mailto:[EMAIL PROTECTED] Sent: Wednesday 04 October 2006 15:36 To: dbi-users Subject: Re: When is a string a number? On Wed, 2006-10-04 at 14:00 -0500, David Nicol wrote: On 10/4/06, Martin J. Evans [EMAIL PROTECTED] wrote: With DBI/DBD::Oracle all values read from the database are scalars. As everyone will know, whether something read from the database is a string or a number in Perl purely depends on the context it is used in so: internally, there are flags in the SV structure that hint as to what conversions have been done on the SV already, for efficiency's sake. As I suspected. I have to admit I don't know how the JSON module knows what is a number and what is a string in Perl but I see the same issue with Data::Dumper so I presume there must be some way to find out if a perl scalar is a number or a string. It seems like the pure perl Dumper tests values with a regex and optimizes to numbers when the stringification matches a number template, while the XS version checks the flags in the SV structure. OK, I only introduced the Data::Dumper example as it seemed very similar but read on - I over simplified a little. However, it seems strange to me that the pure perl Data::Dumper does something different. If I was using Data::Dumper for data interchange and switched from the pure perl to the XS version (or vice versa) and then called another XS based module with the results - they could be different. The problem gets a lot worse for me since I do some arithmetic on values pulled from the database before converting them to JSON and this is where Perl seems to change them into numbers e.g. I don't want to have to do ($var +0) on all the number fields I pull from the database (to turn them into numbers) and neither do I want to do a '$var .= ' (to turn all the fields into strings). you might have to do exactly that. $var will produce a string version. Sorry. This seems amazing - I really did not want to do this. I guess what I'm saying is that it would be really useful for a DBD to mark a number as a number so it does not start as a string and mutate to a number when I do arithmetic on it. Most DBDs must know if the column is a number one or not (certainly DBD::ODBC does). Apparently you can tell the JSON module to make everything strings: http://search.cpan.org/~makamaka/JSON-1.07/lib/JSON.pm#AUTOCONVERT Here was an over simplification. I moved from JSON to JSON Syck. The JSON module is a purl perl module and does the right thing for me for all the cases I tried but I changed to JSON Syck which uses the libsyck library for speed. This explains the difference since JSON Syck is XS and will know the flags in the SV structure and JSON won't. As an aside (and probably a perl question rather than a DBI one) does anyone know why the type of a scalar changes when you use it on the right side of an assignment: perl -MData::Dumper -le '$a=1; print Dumper($a); $b += $a; print Dumper($a);' $VAR1 = '1'; $VAR1 = 1; The has-been-evaluated-as-a-number flag got set on $a when it was evaluated as a number; then Dumper, with both available, chose the number format. That's interesting to know, I'll look into that. I was rather surprised the right hand side of an evaluation changed the type of a variable on the right hand side. How does JSON and Data::Dumper know whether Perl thinks something is a number or a string? inspecting the flags; except pure-perl Dumper apparently uses a regular expression to identify numbers. Those are guesses. The source is available for your inspection. I did look at it briefly but not extensively since it was not my primary problem. Thanks for your insights David, they have increased my understanding although I still feel stuck. I could move back to using the JSON module but I could run into problems with fields like house_name_or_number which I'm now guessing JSON will serialise as a number when it looks like a number and a string when not. If I stick with JSON Syck (which is a lot faster and I need the speed), I'm forced to do +0 on all database fields I know are a number and I don't like this at all. I guess I'm rather surprised to hit this issue without seeing anyone else with it after all this time using DBI. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com - - - - - Appended by
RE: When is a string a number?
On Wed, 2006-10-04 at 15:50 -0400, Rutherdale, Will wrote: This is a very interesting problem, Martin, because most of us ordinary Perl users don't experience these issues on a regular basis if ever. Just one thought, maybe a bit naiive, but wouldn't it be possible to copy all the values you've got from the database and do the extra computations on the copies separately? It might avoid polluting the originals before passing them off to JSON. -Will It would be possible if it were not for the facts that: a) the values computed from the DB values are required in the JSON output. i.e. the perl code does some calculations on DB values that are logic based and difficult to perform in SQL before being transformed into JSON. b) the computations on the DB retrieved values are dependent on what values are returned so sometimes I do a $a += 1 before transforming to JSON and sometimes I don't. This itself means that I can end up with strings in the JSON or numbers depending on what logic is applied to the DB returned values. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com -Original Message- From: Martin J. Evans [mailto:[EMAIL PROTECTED] Sent: Wednesday 04 October 2006 15:36 To: dbi-users Subject: Re: When is a string a number? On Wed, 2006-10-04 at 14:00 -0500, David Nicol wrote: On 10/4/06, Martin J. Evans [EMAIL PROTECTED] wrote: With DBI/DBD::Oracle all values read from the database are scalars. As everyone will know, whether something read from the database is a string or a number in Perl purely depends on the context it is used in so: internally, there are flags in the SV structure that hint as to what conversions have been done on the SV already, for efficiency's sake. As I suspected. I have to admit I don't know how the JSON module knows what is a number and what is a string in Perl but I see the same issue with Data::Dumper so I presume there must be some way to find out if a perl scalar is a number or a string. It seems like the pure perl Dumper tests values with a regex and optimizes to numbers when the stringification matches a number template, while the XS version checks the flags in the SV structure. OK, I only introduced the Data::Dumper example as it seemed very similar but read on - I over simplified a little. However, it seems strange to me that the pure perl Data::Dumper does something different. If I was using Data::Dumper for data interchange and switched from the pure perl to the XS version (or vice versa) and then called another XS based module with the results - they could be different. The problem gets a lot worse for me since I do some arithmetic on values pulled from the database before converting them to JSON and this is where Perl seems to change them into numbers e.g. I don't want to have to do ($var +0) on all the number fields I pull from the database (to turn them into numbers) and neither do I want to do a '$var .= ' (to turn all the fields into strings). you might have to do exactly that. $var will produce a string version. Sorry. This seems amazing - I really did not want to do this. I guess what I'm saying is that it would be really useful for a DBD to mark a number as a number so it does not start as a string and mutate to a number when I do arithmetic on it. Most DBDs must know if the column is a number one or not (certainly DBD::ODBC does). Apparently you can tell the JSON module to make everything strings: http://search.cpan.org/~makamaka/JSON-1.07/lib/JSON.pm#AUTOCONVERT Here was an over simplification. I moved from JSON to JSON Syck. The JSON module is a purl perl module and does the right thing for me for all the cases I tried but I changed to JSON Syck which uses the libsyck library for speed. This explains the difference since JSON Syck is XS and will know the flags in the SV structure and JSON won't. As an aside (and probably a perl question rather than a DBI one) does anyone know why the type of a scalar changes when you use it on the right side of an assignment: perl -MData::Dumper -le '$a=1; print Dumper($a); $b += $a; print Dumper($a);' $VAR1 = '1'; $VAR1 = 1; The has-been-evaluated-as-a-number flag got set on $a when it was evaluated as a number; then Dumper, with both available, chose the number format. That's interesting to know, I'll look into that. I was rather surprised the right hand side of an evaluation changed the type of a variable on the right hand side. How does JSON and Data::Dumper know whether Perl thinks something is a number or a string? inspecting the flags; except pure-perl Dumper apparently uses a regular expression to identify numbers. Those are guesses. The source is available
