Thread: ODBC driver: Rows Affected
Previous (non gborg) versions of the driver return the number of RowsAffected by an Update (didn’t test delete) statement, but this one does not. It seems to always return -1.
Not sure if it’s the odbc interface or the tools I’m using (ADO dataset with Delphi) I am looking at the difference in the ODBC logs and see this: (Query was in a transaction and rolled back)
I read through the archives and saw that this problem was in a patch to the 02 version. Did that patch get into 0003.
Also it was noted that the 0003 version should fix the BDE issue and it has not (which is why I using ADO. The reason I use BDE still is that it seems to behave better with very large record sets and the Declare/Fetch option turned on) I can use ADO but I liked having the flexibility.
The issue (I looked into this while tracking down some Unicode stuff with the old driver) is that the driver returns a data type that is unrecognized by the BDE which then just throws the field away (this is what makes the dbexplorer tool not work)
Hi Nathan, The patch did not get into the 8.01.0003 Release. You have to get the latest CVS version for that. Regards Anoop -----Original Message----- From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Nathan Pfluger Sent: Wednesday, August 24, 2005 3:22 AM To: pgsql-odbc@postgresql.org Subject: [ODBC] ODBC driver: Rows Affected Previous (non gborg) versions of the driver return the number of RowsAffected by an Update (didn't test delete) statement,but this one does not. It seems to always return -1. Not sure if it's the odbc interface or the tools I'm using (ADO dataset with Delphi) I am looking at the difference in theODBC logs and see this: (Query was in a transaction and rolled back) I read through the archives and saw that this problem was in a patch to the 02 version. Did that patch get into 0003. Also it was noted that the 0003 version should fix the BDE issue and it has not (which is why I using ADO. The reason Iuse BDE still is that it seems to behave better with very large record sets and the Declare/Fetch option turned on) I canuse ADO but I liked having the flexibility. The issue (I looked into this while tracking down some Unicode stuff with the old driver) is that the driver returns a datatype that is unrecognized by the BDE which then just throws the field away (this is what makes the dbexplorer tool notwork)
From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Nathan Pfluger
Sent: 23 August 2005 22:52
To: pgsql-odbc@postgresql.org
Subject: [ODBC] ODBC driver: Rows AffectedPrevious (non gborg) versions of the driver return the number of RowsAffected by an Update (didn’t test delete) statement, but this one does not. It seems to always return -1.
This is fixed in CVS and will be in the next snapshot.
Not sure if it’s the odbc interface or the tools I’m using (ADO dataset with Delphi) I am looking at the difference in the ODBC logs and see this: (Query was in a transaction and rolled back)
I read through the archives and saw that this problem was in a patch to the 02 version. Did that patch get into 0003.
No, it was only a few days ago (http://gborg.postgresql.org/cgi-bin/cvsweb.cgi/psqlodbc/connection.c?cvsroot=psqlodbc - see rev 1.106).
Also it was noted that the 0003 version should fix the BDE issue and it has not (which is why I using ADO. The reason I use BDE still is that it seems to behave better with very large record sets and the Declare/Fetch option turned on) I can use ADO but I liked having the flexibility.
The issue (I looked into this while tracking down some Unicode stuff with the old driver) is that the driver returns a data type that is unrecognized by the BDE which then just throws the field away (this is what makes the dbexplorer tool not work)
Yes, that was my conclusion after playing with it for a while. In some circumstances (ie. when you view data on a table), it simply queries and displays the results. However, if you do a SELECT * FROM... it does a SQLDescribeCol on each column first, it then ignores all the SQL_C_WVARCHAR ones (or something like that iirc). Unless I'm missing some subtle point, I can only conclude that dbexplorer/BDE simply doesn't work properly with Unicode - I certainly couldn't find anything wrong in the drivers responses.
:-(
Regards, Dave.