Most likely, your use of {syb_more_results} is wrong. Most likely, this is because you're not using DBD::Sybase but something else. Reduce your code. Write a real small and short script that only connects to the database and fetches the results, instead of pulling in all your other in-house libraries. Throw out the following modules from your sample program:

use KAP; #internally developed library.
use Date::Manip; #internally developed library.
use DBAccess;
use EQ_Misc; #internally developed library.
use DBD::CSV;
use MIME::Lite;
use Net::SMTP;
[download]

Date::Manip likely is not an "internally developed library" anyway. After you've thrown out these, your script should basically look like:

use strict;
use DBI;
use Data::Dumper;
my $dbh = DBI->connect(...);
my $sp = 'lv..check_tax_lot';
warn "Preparing [$sp]";
my $sth = $dbh->prepare($sp);
warn "Running [$sp]";
my $res = $sth->execute();
warn "Got results ($res):";
if (! $res) {
    die $sth->errstr;
};
my $results = $sth->fetchall_arrayref;
print Dumper $results;
[download]

Also, your post should have been a reply below Re: Writing Multiple Recordsets into a CSV file, where you already got a good answer and I consider it good courtesy to at least mention that others have helped you already and where they have.

[ This post assumes you are using DBD::Sybase. ]

You use

do {
   my $row = $_read_sth->fetchrow_arrayref();
   print Dumper $row;
} while ($_read_sth->{syb_more_results});
[download]

Normal use would be

while (my $row = $_read_sth->fetchrow_arrayref()) {
   print Dumper $row;
}
[download]

The docs suggest

do {
   while (my $row = $sth->$_read_sth->fetchrow_arrayref()) {
      print Dumper $row;
   }
} while ($_read_sth->{syb_more_results});
[download]

Not sure what this "syb_more_results" business is about, so I don't know if "Normal" is sufficient or if you need the outer loop, but what you are using now definitely looks wrong.

Not sure what this "syb_more_results" business is about,

It's explained in Re: Writing Multiple Recordsets into a CSV file and (of course) the DBD-Sybase docs. It got confusing when a whole new thread was started instead of following up on the existing one.
--
Andreas

Following is my code now as per your suggestion:

#!/cluster/uapp/perl/bin/perl -w
use KAP;
use strict;
use Date::Manip;
use DBAccess;
use EQ_Misc;
use DBD::CSV;
use MIME::Lite;
use Net::SMTP;
use Data::Dumper;

  my $_db_lv_conn_file = "MSLV.eq_script_user";
  my $_read_dbi = undef;

            # Run stored proc
    my $sp = "longview..norges_integrity_check_tax_lot";

    KAP::write_log("Preparing $sp");
    $_read_dbi = KAP::opendbi($_db_lv_conn_file) || handle_error_and_e
+xit ("Failed to get a connection to MSLV db server");
    my $_read_sth = $_read_dbi->prepare($sp);
    if($DBI::err) {
        handle_error_and_exit("**ERROR preparing $sp: " . $DBI::errstr
+);
    }
    KAP::write_log("Prepare done, executing $sp");

    $_read_sth->execute();
    if($DBI::err) {
        handle_error_and_exit( "**ERROR executing $sp: " . $DBI::errst
+r);
    }
    KAP::write_log("Execute of $sp done");
    
    
    my $_datafile = KAP::datafile();   
    my $numrecords = 0;
    my @data = undef;
    
   do{
    while (my $row = $_read_sth->fetchrow_arrayref())
   {
     print Dumper $row;
   }
}  while ($_read_sth->{syb_more_results});
[download]

But the output doesn't contain any column headers and only returns the first resultset as follows:

nbsda1@vcstest3$ perl sudip.pl

$VAR1 = [
          '15140EQJP_55121',
          'DD UN',
          '2018175',
          'DU PONT (E.I.) DE NEMOURS',
          'BO data mismatch',
          '275000.0',
          '98027EQJP_54981'
        ];

$VAR1 = [
          '15140EQJP_55121',
          'CMI UN',
          '2240202',
          'CUMMINS INC',
          'BO data mismatch',
          '100000.0',
          '98059EQJP_53421'
        ];
$VAR1 = [
          '15140EQJP_55121',
          'DOW UN',
          '2278719',
          'DOW CHEMICAL',
          'BO data mismatch',
          '175000.0',
          '98027EQJP_54981'
        ];

nbsda1@vcstest3$
[download]

But basically what I want is that whatever the stored procedure returns(all the 7 resultsets), just to dump that on the screen with all the header columns etc.

I also do not need this $VAR1 = [ ];

Basically I want to write the output as dumped by stored procedure into a .csv file which I would need for some other purpose. But before I try to write the output into the .csv file I just wanted to print the output on the screen and see how it looks.

Any help?

Corion already suggested you replace the home-grown KAP module with the more robust DBI CPAN module. You haven't done that.

Try fetchrow_hashref() instead of fetchrow_arrayref(). You are using Data::Dumper. It dumps. It does not format. You have to do the formatting yourself. Read up of Perl hashes for a start.
--
Andreas

Great! It works!

I also do not need this $VAR1 = [ ];

Data::Dumper is a debugging tool, meant to show data in an umambiguous format. It's now up to you to replace it with the output code you desire.

while( my $row = $_read_sth->fetchrow_arrayref() ) {
  print Dumper $row;
}
[download]

You still haven't told us about KAP? Does it return a DBD object? If so, which one - DBD::Sybase, DBD::Oracle or something else? Or is it a wrapper around a DBD object? If so, does KAP expose the necessary methods/members to traverse multiple result sets. Until you can tell us more about KAP, every answer here is just MJD 11900 or (my favorite) 11901.

Searching our home grown Module Documentation this is what I get:
DBI FUNCTIONS

dbidata

Returns connection data for initializing a DBI connection.

opendbi

Returns a DBI object. Se the DBI documentation for what to to with it.

Usage: my $dbi = KAP::opendbi( 'SYBASE.eq_script_user' ); $dbi->do(``SELECT * FROM people WHERE nice = 'very''');

For this example to work, a configuration file called dbi.SYBASE would have to be created, and it needs to contain values for 'data_source', 'username' and 'password'

data_source=SYBASE
username=eq_script_user
password=secret

or full data_source:

data_source=dbi:ODBC:ms_servosl12
username=eq_script_user
password=secret

or

data_source=dbi:Sybase:server=SYBASE
username=eq_script_user
password=secret

Well ... that's interesting ... so the dbd object can be either DBD::Sybase or DBD::ODBC ... so which is yours? The way to handle multiple resultsets is DBD driver dependant.

-derby