Re: Facing issue with driver postgresql-9.2-1003.jdbc4 on PostgreSQL 9.2.4

Hi Dave,

Thanks for the information.

Does that mean the behaviour with binaryTransfer=false in
postgresql-9.2-1003.jdbc4 is same as what we have with
postgresql-9.1-903.jdbc4 driver?

Regards,
Nishant

On 29/07/2013 16:20, Dave Cramer wrote:
>
>
> Nishant,
>
> Binary transfer was added and I think I am going to default it to
> false going forward. It *should* be faster but apparently there are
> some bugs in it.
>
> Dave
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Mon, Jul 29, 2013 at 11:16 AM, Nishant Singh
> <nishant(dot)singh(at)egsgroup(dot)com <mailto:nishant(dot)singh(at)egsgroup(dot)com>> wrote:
>
> Hi,
>
> binaryTransfer=false corrected the problem (I changed url to
> "jdbc:postgresql://localhost:5434/db?binaryTransfer=false").
>
> What is the difference between postgresql-9.2-1003.jdbc4 and
> postgresql-9.1-903.jdbc4 drivers in terms of binaryTransfer?
>
> Regards,
> Nishant
>
>
>
> On 29/07/2013 14:37, Dave Cramer wrote:
>>
>> Nishant,
>>
>> The old driver should work fine with pg 9.2 I am wondering if
>> this is an artifact of the binary transfer,
>>
>> Can you try with binaryTransfer=false
>>
>> Dave Cramer
>>
>> dave.cramer(at)credativ(dot)ca
>> http://www.credativ.ca
>>
>>
>> On Mon, Jul 29, 2013 at 9:14 AM, Nishant Singh
>> <nishant(dot)singh(at)egsgroup(dot)com <mailto:nishant(dot)singh(at)egsgroup(dot)com>>
>> wrote:
>>
>> Hi Dave,
>>
>> Thanks for your reply.
>>
>> In my latest test I have noticed that with new jdbc driver
>> (postgresql-9.2-1003.jdbc4.jar), out of total 512 records
>> only first 125 records are having non-null value for type
>> 'character varying[15)[]' field and for the rest of the
>> records (from 126 to 512) field value is null.
>>
>> But with old jdbc driver (postgresql-9.1-903.jdbc4.jar) all
>> 512 records are having non-null value for type 'character
>> varying[15)[]' field.File Comparison-of-results.jpg shows the
>> comparison of test logs (OldDriverWithCursor.txt and
>> NewDriverWithCursor.txt) for the two drivers.
>>
>> I am not sure whether above is of any help in understanding
>> the actual problem or not.
>>
>> By the way we are planning to revert back to old jdbc driver
>> (postgresql-9.1-903.jdbc4.jar) on the live environment having
>> PostgreSQL 9.2.4 till we can find any solution for the problem.
>>
>> Do you think that there can be some issue (in general) with
>> old jdbc driver(postgresql-9.1-903.jdbc4.jar) and PostgreSQL
>> 9.2.4 combination?
>>
>> Regards,
>> Nishant
>>
>>
>> On 29/07/2013 11:41, Dave Cramer wrote:
>>>
>>> Nishant,
>>>
>>> Your email does suggest there is a bug in there somewhere.
>>> However we would require a bit more of a detailed test case
>>> in order to be able to help find it.
>>>
>>> Regards,
>>>
>>> Dave Cramer
>>>
>>> dave.cramer(at)credativ(dot)ca
>>> http://www.credativ.ca
>>>
>>>
>>> On Fri, Jul 26, 2013 at 11:54 AM, Nishant Singh
>>> <nishant(dot)singh(at)egsgroup(dot)com
>>> <mailto:nishant(dot)singh(at)egsgroup(dot)com>> wrote:
>>>
>>> Hi,
>>>
>>> My Java web application uses PostgreSQL. It has a
>>> document table with one of the field called accountCode
>>> of type character varying(15)[]
>>>
>>> In the logictable records are accessed through cursor.
>>> Thats is being done through Apache Torque.(schema.xml:
>>> ...<table name="document" idMethod="native">... <column
>>> name="accountCode" type="CLOB"
>>> javaName="AccountCodeString"/>..)
>>>
>>> PostgreSQL log for the cursor are as follows:
>>> 2013-07-26 15:14:00 BST 9592 efed-328 postgresLOG:
>>> execute <unnamed>: DECLARE CursIt4 CURSOR FOR SELECT
>>> document.DOCUMENTID, document.DOCUMENTNUMBER,
>>> document.ADHOCDOCUMENTNUM, document.ORGUNITID,
>>> document.ACCOUNTID, document.TEMPLATEID,
>>> document.REFDOCUMENTID, document.DOCUMENTTITLE,
>>> document.STATUSID, document.STATUSSTR,
>>> document.DOCUMENTDATE, document.MODTYPEID,
>>> document.DELETEFLAG, document.CURRENTSTEP,
>>> document.ITEMSREADONLY, document.ISCLOSEDFOREINVOICING,
>>> document.ENABLEAUTOACDISTRIBUTION, document.MODDATE,
>>> document.DEADLINE, document.ACCOUNTCODE,
>>> document.EXTERNALID, document.MULTIPLESHIPPING,
>>> document.MULTIPLEBILLING, document.MULTIPLEACCOUNTING,
>>> document.DOCUMENTDESCRIPTION, document.REVISERNAME,
>>> document.REVISEREMAIL, document.REVISERORGUNITNAME,
>>> document.FORWARDREFID, document.REVISIONDATE,
>>> document.RESPONSEVENDORID, document.RESPONSECATALOGUEID,
>>> document.COURIERNAME, document.COURIERTRACKINGNO,
>>> document.WORKFLOWINSTANCEID, document.WORKFLOWEVALUATED,
>>> document.PURCHASEORDERVENDORID,
>>> document.PURCHASEORDERCATALOGUEIDS,
>>> document.NOTIFYSUPPLIER, document.PURCHASEORDERVARIANT,
>>> document.MOD, document.ISQUICKORDER,
>>> document.CONFIRMATIONORDER,
>>> document.WITHDRAWNFROMAPPROVAL, document.SHIPPINGDATE,
>>> document.FMSNAME, document.EXTERNAL_REF_ID,
>>> document.ISCISORDER, document.ISPROXY,
>>> document.ORIGINAL_PO_ID, document.NUMBER_OF_VARIATIONS,
>>> document.ORIGINAL_ORDER_DATE, document.SHARED_SECRET
>>> FROM document, organizationalUnit WHERE
>>> document.ISPROXY<>1 AND organizationalUnit.ORGID=15136
>>> AND document.STATUSID IN
>>> (1457,1456,1459,1458,1453,1466,1452,1455,1454,1450,1461,1470,1451)
>>> AND document.ORGUNITID=organizationalUnit.ORGUNITID
>>> ...
>>> 2013-07-26 15:14:00 BST 9592 efed-328 postgresLOG:
>>> execute <unnamed>: FETCH 25 FROM CursIt4
>>> ...
>>>
>>> We have recently moved to PostgreSQL 9.2.4 and JDBC
>>> driver postgresql-9.2-1003.jdbc4.jar. But we have
>>> noticed that now accountcode field is not getting
>>> populated in the Java code. Same is happening with
>>> postgresql-9.2-1002.jdbc4.jar
>>>
>>> Earlier with PostgreSQL 9.1.4 and JDBC driver
>>> postgresql-9.1-903.jdbc4.jar we were getting accountCode
>>> field populated in the Java code.
>>>
>>> But when we change to JDBC driver
>>> postgresql-9.1-903.jdbc4.jar on PostgreSQL 9.2.4 it
>>> works fine.
>>>
>>> Are new drivers (postgresql-9.2-1003.jdbc4and
>>> postgresql-9.2-1002.jdbc4) having some bug which is
>>> causing this problem or therecan be some other reason?
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> Nishant
>>>

This message has been scanned for malware by SurfControl plc. www.surfcontrol.com