Re: [JDBC] Displaying/Pulling Images using JDBC ...

2001-05-13 Thread Tom Lane

Bruce Momjian <[EMAIL PROTECTED]> writes:
> !   int ret = (buffer[bpos] & 0x7F);
> !   if ((buffer[bpos] &0x80) == 0x80) {
> ! ret |= 0x80;
> !   }

That seems like an awfully ugly (and slow) way of doing unsigned
promotion.

If Java doesn't have a notion of unsigned chars, perhaps this would do:

return ((int) buffer[bpos++]) & 0xFF;

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl



RE: [JDBC] Displaying/Pulling Images using JDBC ...

2001-05-13 Thread Ho, Khanh

Hi Marc,

I seem to be having the same problem as you when trying to insert 
audio files into the database. They are inserted OK using 
PreparedStatement.setBinaryStream(), but the data is truncated
when retrieved using PreparedStatement.getBinaryStream().
This occurs using the jdbc7.1beta5 driver.

Interestingly, when I try to use an older JDBC driver (jdbc7.1beta4), it
manages to correctly read back the object stored by the jdbc7.1beta5 driver.
However, the jdbc7.1beta4 driver itself can't write the large object to the 
database. It keeps throwing an exception:   InputStream as parameter not
supported.

Can you let me know if you find out the cause of the problem, or
better still a solution?

Thanks,
Khanh Ho.


> -Original Message-
> From: The Hermit Hacker [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, 13 May 2001 2:45 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [JDBC] Displaying/Pulling Images using JDBC ...
> 
> 
> 
> 
> Morning folks ...
> 
>   Been wracking our brains on this one for too long now ... have a
> client that is trying to use JDBC to pull images stored in 
> the database,
> and, from what we can gather, the images are coming out 
> 'truncated' ...
> 
>   If the client stores the images as ASCII (uuencoded) and pulls
> those out, all works well, but if he stores them as 
> binary/raw images, the
> images don't come out ...
> 
>   If he retrieves that image using psql and stores it to a file,
> that file is fine, so apparently the backend is storing it 
> properly ...
> 
>   According to the table schema that we have, the image is being
> stored as an 'oid' type ...
> 
> In relation to the image settings, they are counting the bytes
> that the stream is going to send to the client and verifying it on the
> clients side, the numbers are not matching unless it is an ascii based
> file
> 
>   Both the backend server and the JDBC drivers are v7.1 ...
> 
>   Now, my thought on this is that it *sounds* like the JDBC is
> hitting some sort of control character is the stream that 
> tells it to stop
> sending the image ... is this possible?  Some binary 
> character that needs
> to somehow be trapped?
> 
>   Image content is a mostly a faxed document saved as .tif format.
> But it could be anything and we derive it from the file name. 
>  We upload
> the document to the database.  Please See the source
> 
>   Sample of the source they are using is as follows, is 
> there something
> that we are seeing:
> 
> PreparedStatement prepStmt = con.prepareStatement(selectstatement);
> prepStmt.setString(1, medicalRecordId);
> ResultSet rs = prepStmt.executeQuery();
> if (rs.next()) {
>   medicalRecordId = rs.getString(1);
>   typeSOAP = rs.getString(2);
>   code = rs.getString(3);
>   String datetimetemp = rs.getString(4);
>   datetime = Timestamp.valueOf(datetimetemp);
>   testObject = rs.getString(5);
>   testResult = rs.getString(6);
>   note = rs.getString(7);
>   appointmentId = rs.getString(8);
>   patientId = rs.getString(9);
>   test = rs.getString(10);
>   category = rs.getString(11);
> 
>   //if(imageName == null){
>   if(imageNametemp != null){
>  imageName = rs.getString(12);
> 
> 
>  BufferedInputStream bis = new 
> BufferedInputStream(rs.getBinaryStream(13));
>  System.out.println("value of bis"+bis.toString());
>  //InputStream is = rs.getBinaryStream(13);
> 
>  //System.out.println("vale of inputstream"+is.toString());
> 
>  int TotLen=0;
> 
>  ByteArrayOutputStream imageOutputStream = new 
> ByteArrayOutputStream(8164);
> 
>  byte[] b = new byte[8164];
>  int len=0;
> 
>  try {
>while( (len = bis.read(b,0,8164)) != -1 ) {
>  imageOutputStream.write(b,0,len);
> 
>  TotLen += len;
>}
>bis.close();
>imageAsBytes = imageOutputStream.toByteArray();
> 
>System.out.println("value of baoslenght"+imageAsBytes.length);
>System.out.println("value of totlenght"+TotLen);
> 
>System.out.println("vale of 
> baos"+imageOutputStream.toString());
>  }
>  catch(IOException e) {
>  }
>   }
> prepStmt.close();
> 
> 
> Marc G. Fournier   ICQ#7615664   
> IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED]   secondary: 
> scrappy@{freebsd|postgresql}.org
> 
> 
> ---(end of 
> broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to 
> [EMAIL PROTECTED])
> 

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [JDBC] Displaying/Pulling Images using JDBC ...

2001-05-12 Thread The Hermit Hacker

On Sat, 12 May 2001, Tom Lane wrote:

> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Now, my thought on this is that it *sounds* like the JDBC is
> > hitting some sort of control character is the stream that tells it to stop
> > sending the image ... is this possible?  Some binary character that needs
> > to somehow be trapped?
>
> Embedded nulls would be the likely cause of trouble.
>
> If you're seeing OIDs in the database then the actual storage is
> presumably in large objects.  lo_read and friends are null-safe as far
> as I know; probably the problem is somewhere inside the JDBC driver.

that's kinda what I'm figuring too ... the question is where, and is there
a suitable work around ;(



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [JDBC] Displaying/Pulling Images using JDBC ...

2001-05-12 Thread Tom Lane

The Hermit Hacker <[EMAIL PROTECTED]> writes:
>   Now, my thought on this is that it *sounds* like the JDBC is
> hitting some sort of control character is the stream that tells it to stop
> sending the image ... is this possible?  Some binary character that needs
> to somehow be trapped?

Embedded nulls would be the likely cause of trouble.

If you're seeing OIDs in the database then the actual storage is
presumably in large objects.  lo_read and friends are null-safe as far
as I know; probably the problem is somewhere inside the JDBC driver.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



[JDBC] Displaying/Pulling Images using JDBC ...

2001-05-12 Thread The Hermit Hacker



Morning folks ...

Been wracking our brains on this one for too long now ... have a
client that is trying to use JDBC to pull images stored in the database,
and, from what we can gather, the images are coming out 'truncated' ...

If the client stores the images as ASCII (uuencoded) and pulls
those out, all works well, but if he stores them as binary/raw images, the
images don't come out ...

If he retrieves that image using psql and stores it to a file,
that file is fine, so apparently the backend is storing it properly ...

According to the table schema that we have, the image is being
stored as an 'oid' type ...

In relation to the image settings, they are counting the bytes
that the stream is going to send to the client and verifying it on the
clients side, the numbers are not matching unless it is an ascii based
file

Both the backend server and the JDBC drivers are v7.1 ...

Now, my thought on this is that it *sounds* like the JDBC is
hitting some sort of control character is the stream that tells it to stop
sending the image ... is this possible?  Some binary character that needs
to somehow be trapped?

Image content is a mostly a faxed document saved as .tif format.
But it could be anything and we derive it from the file name.  We upload
the document to the database.  Please See the source

Sample of the source they are using is as follows, is there something
that we are seeing:

PreparedStatement prepStmt = con.prepareStatement(selectstatement);
prepStmt.setString(1, medicalRecordId);
ResultSet rs = prepStmt.executeQuery();
if (rs.next()) {
  medicalRecordId = rs.getString(1);
  typeSOAP = rs.getString(2);
  code = rs.getString(3);
  String datetimetemp = rs.getString(4);
  datetime = Timestamp.valueOf(datetimetemp);
  testObject = rs.getString(5);
  testResult = rs.getString(6);
  note = rs.getString(7);
  appointmentId = rs.getString(8);
  patientId = rs.getString(9);
  test = rs.getString(10);
  category = rs.getString(11);

  //if(imageName == null){
  if(imageNametemp != null){
 imageName = rs.getString(12);


 BufferedInputStream bis = new BufferedInputStream(rs.getBinaryStream(13));
 System.out.println("value of bis"+bis.toString());
 //InputStream is = rs.getBinaryStream(13);

 //System.out.println("vale of inputstream"+is.toString());

 int TotLen=0;

 ByteArrayOutputStream imageOutputStream = new ByteArrayOutputStream(8164);

 byte[] b = new byte[8164];
 int len=0;

 try {
   while( (len = bis.read(b,0,8164)) != -1 ) {
 imageOutputStream.write(b,0,len);

 TotLen += len;
   }
   bis.close();
   imageAsBytes = imageOutputStream.toByteArray();

   System.out.println("value of baoslenght"+imageAsBytes.length);
   System.out.println("value of totlenght"+TotLen);

   System.out.println("vale of baos"+imageOutputStream.toString());
 }
 catch(IOException e) {
 }
  }
prepStmt.close();


Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])