Skip to Content.
Sympa Menu

freetds - RE: ct_get_data problems: always gets the same wrong data

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Eric Deutsch" <edeutsch AT systemsbiology.org>
  • To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
  • Subject: RE: ct_get_data problems: always gets the same wrong data
  • Date: Tue, 13 Aug 2002 11:21:26 -0700



Hi Chris, I was playing with getting IMAGE data in Perl a while back and
got it working with a few patches which I sent to the list, but I'm not
certain if they were applied. But I was doing it differently than what
you do. I've never seen $sth->func() used before.

When I run your code on a recent snapshot, I get a similar result as you
at:

$fetchedLength = $sth->func( 2, \$fileBlob, 0, 'ct_get_data' );

I'm not sure anyone has tried this before. It does not appear to me at
first glance that the parameters are identical in FreeTDS and
DBD::Sybase for ct_get_data. I'd be interested in seeing this work,
though.

I was able to get IMAGE reading to work with a hack like:

SELECT file_id,file_name,file_contents FROM file_test

while (@row = $sth->fetchrow_array ()) {
open (OUTFILE,">$row[1]") || die "Unable to open $row[1] for writing";
print OUTFILE
pack("H".(length($row[2])-2),substr($row[2],2,1024*1024));
close(OUTFILE);
}

This is clearly pretty inefficient since the data is converted to ASCII
first and then decoded, but it seems to work fine.

I have not tried this on the latest snapshot.

Eric


> -----Original Message-----
> From: Chris Wesley [mailto:cwwesley AT udlug.org]
> Sent: Monday, August 05, 2002 3:40 PM
> To: TDS Development Group
> Subject: [freetds] ct_get_data problems: always gets the same wrong
data
>
> I'm using perl (5.6) with DBI (1.28), DBD::Sybase (0.93) and freetds
> (0.53) to retrieve data from a M$ SQL2000 server.
>
> Executing queries and retrieving non-text and non-image columns works
> beautifully. But I'm trying to fetch an image column too, and I've
> finally run across a snag for which I haven't found a solution. Every
> time I invoke the ct_get_data() function to get the contents of an
image
> column, I always get some ridiculous string that is at least 136391000
> bytes long (by using some dbi/dbd settings, the bytecount may change
by a
> a few dozen bytes). Using sqsh (2.1), I can get the column just fine.
> It doesn't matter what the actual length of the content of the column
is
> ... I always get the same result (which is an improvement over the
> segfaults I finally resolved).
>
> Perl Script ensuing:
>
> #!/usr/bin/perl -w
> use strict;
> use DBI;
> my $M_HOST = "myHost";
> my $M_DB = "myDB";
> my $M_USER = "myUser";
> my $M_PASSWD = "myPasswd";
> my $M_DSN = "dbi:Sybase:database=${M_DB};server=${M_HOST}";
> my $MAX_BLOB_SIZE = 1024 * 512;
> my $dbh = DBI->connect( $M_DSN, $M_USER, $M_PASSWD ) or die ("Connect
> Failed.");
> $dbh->{LongReadLen} = $MAX_BLOB_SIZE;
> $dbh->do( "set textsize ${MAX_BLOB_SIZE}" );
> #################################################
> my( $sth, $row, $fileName, $fetchedLength, $fileBlob );
> $fileBlob = '';
> $sth = $dbh->prepare("select FileName, FileBlob from Doc where
DocID=8");
> $sth->execute;
> while( $row = $sth->fetchrow_arrayref ){
> print( "HOLD ON\n" );
> $fetchedLength = $sth->func( 2, \$fileBlob, 0, 'ct_get_data' );
> print( "Fetched Length: ${fetchedLength}\n" );
> print( "HELD ON\n" );
> }
> $sth->finish();
> $dbh->disconnect();
> # END OF SCRIPT
>
> -- The output is ALWAYS --
> HOLD ON
> Fetched Length: 136391200
> HELD ON
> --
> In this case, the binary stored is 33 bytes. (I get a 66 byte hex
string
> from sqsh, which is correct, and properly packs back into the original
> file.)
>
> Does anyone here know what might cause this behavior? Or know of a
> different/better way to do what I'm doing?
>
> I also have freetds sending debug info to a log file. I don't see
> anything of note there, but if anyone thinks it'd be more helpful to
see,
> let me know. If I haven't adequately described the problem, feel free
to
> call me out on it, and I'll try to describe it better.
>
> TIA for any suggestions,
> ~Chris
>
>
> ---
> You are currently subscribed to freetds as:
[edeutsch AT systemsbiology.org]
> To unsubscribe, forward this message to leave-freetds-
> 127899P AT franklin.oit.unc.edu




Archive powered by MHonArc 2.6.24.

Top of Page