Re: DBIx::Chart real Candlestick
Christian Maier wrote: Hello Do anybody know how to draw a real candlesick bar chart with open, high, low, close instead of high and low? A real candlestick = http://tinyurl.com/3yayg7 DBD::Chart candlestick = http://www.presicient.com/dbdchart/dbdchart_frame.html#candlestick Maybe I can combine 2 kind of charts to make it look like a real candlestick? Thanks for Help! Christian Maier Sorry, no (or not yet). Another item on the (altogether too long) TODO list, and I don't know when I'll be able to get a new release out. Patches welcome. You might be able to hack something with stacked floating barcharts, but thats probably as close as you'll get with the current code. Dean Arnold Presicient Corp.
Re: FW: Double Quoting in Table names causing dynamic method access failures
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I agree that Class::DBI may be involved. However, the module Class::DBI
specifically is not installed.
There is no doubt that Class::DBI is intimately involved here. The error
is coming from:
/usr/lib/perl5/site_perl/5.8.8/Class/DBI/Loader/Generic.pm
In this file, the following method is called:
(In this method the value of $table is 'access'; and I do mean '(double
quote)access(double quote)' (without the single quotes of course). The
double quoting of the table name is where the problem stems from.)
Begin Method
sub set_up_table {
my ( $class, $table, $opts ) = @_;
...
SELECT a.attname, a.attnum
FROM ${catalog}pg_class c, ${catalog}pg_attribute a
WHERE c.relname = ?
Yep, that's the problem. Looks like DBI::Class is mixing and matching
relation names. If they want to use the tablenames raw for use in
system catalogs, they should probably be getting the table names
themselves: I suspect they are getting them through DBI/DBD::Pg, which is
properly quoting them. The quotes are for people doing things like
$SQL = UPDATE $table SET foo=12 WHERE foo=24;
The only time the quotes will mess things up is when people do things like
try to put those values directly into pg_class.
Alternatively, there are aready DBI methods to get the primary key
for a table: see primary_key_info. This looks like a Class::DBI bug:
they need to either get all the information themselves via the system
catalogs, or rely on DBI (via DBD::Pg) to get it for them. The mixing
and matching is causing the problems.
I'm not very familiar with Class::DBI, but I'd definitely check there
first, and see if this has been reported on a mailing list or a bug
report, or raise the issue on one or both yourself.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200707311122
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-
iD8DBQFGr1PKvJuQZxSWSsgRAx0nAJ4h/OlaYMtXOF/G4Ys8lizHoNoR/gCbBj7R
px/gMXv6obk8Bgwph46+RfQ=
=meqs
-END PGP SIGNATURE-
Getting DBD::Ingres for ActivePerl
Hello, I try to get DBD::Ingres working for ActivePerl, but I have som problems to get it compiled correctly (in one word : it works on the machine with the dev environment, but I cannot manage to deploy it). Do you have any clue about getting the PPM already done ? Many thanks.
Re: Announce: Slides for Advanced DBI Tutorial 2007
Any chance somebody recorded the audio for a Pod/Perlcast? On 7/30/07, Tim Bunce [EMAIL PROTECTED] wrote: file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_200708.pdf size: 494172 bytes md5: bc04cc4f1780457cccbede8529c8726b 119 pages... Enjoy! Tim. -- Matthew O. Persico
Re: DBIx::Chart real Candlestick
http://gnuplot.sourceforge.net/demo_4.3/candlesticks.html On 7/31/07, Dean Arnold [EMAIL PROTECTED] wrote: Christian Maier wrote: Hello Do anybody know how to draw a real candlesick bar chart with open, high, low, close instead of high and low? -- Prioritize based on common sense? Is that some kind of joke?
Guidance on setting up multiple database handles to be used in one script
Over time the need to connect to the same database in different scripts became apparent. To do this I began by creating a package that contained all the $dbh handles (not advisable) as if one fails then your whole script is no good. So I then split them into individual packages for each connect handler. Again not good if you need to connect to multiple databases in your script, but aren't dependent on all of them having to work. So is there a good way to manage database connections only. So that multiple scripts can use the same connection but it is defined in the one place. Should I explore DBI::Ingres. or is there another easier way, other than defining the connection in each script I create.
dbi access ODBC
Hi Martin, you directed me to an article by microsotf to fix an error which is caused when my perl script access a access97 file.The article tell to chk the windows temp folders. that time I got the problem fixed on my XP machine. This time, I am having the same error on a windows server 2003. exactly the same erorr. could you please tell me how to get it fixed? Much appreciate it. Samuel
Fw: dbi access ODBC
Hi Martin, the error is different this time. It said SQL-42000, please help! - Original Message - From: Samuel_Zheng To: dbi-users@perl.org Sent: Tuesday, July 31, 2007 11:04 PM Subject: dbi access ODBC Hi Martin, you directed me to an article by microsotf to fix an error which is caused when my perl script access a access97 file.The article tell to chk the windows temp folders. that time I got the problem fixed on my XP machine. This time, I am having the same error on a windows server 2003. exactly the same erorr. could you please tell me how to get it fixed? Much appreciate it. Samuel
error
this is the error message, Because it on a Chinese 2003 server and the chinese
is missing some bytes. I cannot read what it says. Does anyone can tell what it
means and suggest things to try?
thanks,
samuel
Software error:
DBI connect('btn','',...) failed: [Microsoft][ODBC Microsoft Access Driver] uEz
(SQL-42000)(DBD: db_login/SQLConnect err=-1) at C:\web\validate.pl line 130
Comments on stability of SQLite for storage
Greetings. I'm beginning a project where I have to store some stuff on the disk somehow. At present, I'm using SQLite *only* for temporary storage. I had planned to dump data ( which is basically config data, but is absolutely critical in terms of keeping the project held together ) to either XML or CSV, but now this is getting more cumbersome that I'd expected. Who has some anecdotal evidence about the reliability of SQLite files for storing data? Should I drop the XML / CSV idea and just use SQLite? -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au
