AUUUUUUGGGGGGHHHHHH!!!! My Eyes!!!

Let me direct your attention to some of the rules of how to post here. Pay special attention to markup methods used here in the Monastery. I'd live to try and answer your post, but I can't read the thing.

Please edit your post and add some code tags to your post.

Sorry about that buddy, I did not know about markup rules. Thank you for letting me know. SDJ

When you run into errors or unexpected results in DBI related scripts, why not have DBI help you to show it?

my $db_server   = "";
my $host        = $db_server;
my $db          = "";
my $db_user     = "";
my $db_password = '';
my $dbh = DBI->connect("dbi:Oracle:$host",
    $db_user,     # Do NOT quote a simple variable (yes, undef is vali
+d)
    $db_password, # Do NOT quote a simple variable (yes, undef is vali
+d)
    {   RaiseError         => 1,   # Let DBI crash on errors
        PrintError         => 1,   # And have it shaw what fails
        ChopBlanks         => 1,   # Mostly a good idea
        ShowErrorStatement => 1,   # You'll want to see the statement
        FetchHashKeyName   => "NAME_lc",  # Be predictable for field n
+ames
        LongReadLen        => 0x7FFFF,    # How big is your data?
        }
    ) or die "Couldn't connect to database: ".DBI->errstr;
[download]

When that still doesn't help, you want to peek at DBI's trace.

As you are a poor user that connects to Oracle (we all know that Oracle sucks beyond belief in many ways, but to be honest, so do most - if not all - other databases as well), you will probably also have to check out the LongReadLen (you already do, but I don't know how well length returns the correct size(s)) and LongTrunkOk attributes. For Oracle they do matter (a lot).

Last but not least, check out bind_param (something like  $sth->bind_param (1, $in_blob, { ora_type => SQLT_BIN });) and how Oracle deals with it.

Hi i am executing two commands from my perl script.
1. zcat ... | gzip huge file. &
it takes lots of time
2. java huge file &
after above 1. is done.
how can i do this?
Please help.
Thanks,
SDJ

In other words: The image is damaged on the way to the browser. Save the broken image in the browser, open the saved image in a TEXT editor, and look at what your code really sent to the browser.

Looking at your code, it seems the image is not sent to the browser at all. Instead, it is written to a file named output.png. Your code also does not send out any CGI headers. The code lacks all error checks, for the file operations (open, hint: autodie), and for DBI operations (hint: RaiseError => 1).

You should use the three-argument form of open, it has fewer surprises; and use a variable instead of a bareword. (Hint: open my $file,'>','output.png' or die "Can't open output.png: $!";.)

The CGI::Carp option warningsToBrowser inserts HTML data into the output at random locations, and it gives attackers unwanted insights into your code. Remove it from production code. The CGI::Carp option fatalsToBrowser appends CGI headers and HTML data to the output, even if you have already sent CGI headers and data. It also gives attackers unwanted insights into your code. Remove it from production code. Make sure that your code can't die after writing the first CGI header.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)