TUniQuery.CanModify is False after upgrade to UniDAC 8.4.4

[CristianP]

Upgrading from UniDAC 8.3.2 to 8.4.4 TUniQuery.CanModify is False for a simple query:
"SELECT * FROM Umpluturi"
PostgreSQL 9.3.25 on Linux

Changing to ProtocolVersion=pv20 is working again.
On same PostgreSQL 9.3.25 cloned some time ago with whole VM is working,

Are there other solutions than reinstalling the server?

[CristianP]

I observed that all tables created starting with 05.2021 are affected. Probably something changed in April on this server.

When I have direct accesses to the server I will compare posgresql.conf between the server with the issue and the cloned one without the issue.
Any idea what else can I check?

[evgeniym]

Hi Cristian,
Unfortunately, we could not reproduce the described issues. Most of all, this problem is related to the server settings.
Please send us a sample which uses UniDAC and demonstrates incorrect behavior along with DDL scripts to create and fill-in database objects and server configuration files where UniDAC works incorrectly using our contact form:
https://devart.com/company/contactform.html

Regards,
Evgeniy

[CristianP]

It's only one server where this happens. And only on new created tables.
I created a table like this:

Code: Select all

CREATE TABLE winglass.test (a integer) WITH (OIDS=FALSE);

All fields are set to ReadOnly (then TUniQuery.CanModify is False) because in CRAccess.TCRFieldDesc.SetFieldReadOnly() TableInfo is nil. Any clue why?

I will try to debug to see why TableInfo is nil (in 8.3.2 TableInfo is not nil).

[CristianP]

Deleted because is tot relevant.

[CristianP]

All fields are set to ReadOnly (then TUniQuery.CanModify is False) because in CRAccess.TCRFieldDesc.SetFieldReadOnly() TableInfo is nil.

TableInfo is nil because in procedure PgClassesUni.TPgSQLRecordSet.ProcessExtFieldsInfo() there is a check:

Code: Select all

      if UseProtocol30 then begin
        Assert(RecordSet <> nil);
        if FieldDesc.TableOID > 0 then begin

But here FieldDesc.TableOID = -1665140219 and FieldDesc.TableInfo is not set because this.

[CristianP]

I changed in PgClassesUni.TPgSQLRecordSet.ProcessExtFieldsInfo() to check if FieldDesc.TableOID is not zero and now it works.

Code: Select all

      if UseProtocol30 then begin
        Assert(RecordSet <> nil);
        if FieldDesc.TableOID <> 0 then begin

I am not sure if OID can be 0 so I do not know for sure if my solution is a good one.
Can you confirm if next UniDAC update will have this solved?
What else can I do?

My fault was to create all tables "WITH OIDS" and some months ago I dropped out this but too late. OID surpassed 2^31-1.

[CristianP]

Unfortunately, we could not reproduce the described issues.

Because your server OID has not exceeded maximum Int32 value 2^31-1.

[evgeniym]

Hi Cristian,
Thank you for your reply!

We are currently investigating the reasons causing this error.
Could you please execute this request in PgAdmin and write us the result:

Code: Select all

SELECT oid, relname, reltype FROM pg_class where relname IN ('table_name')

,where table_name is the name of the table you are dealing with.

Regards,
Evgeniy

[CristianP]

"oid";"relname";"reltype"
2626708476;"umpluturi";2626708478
2629818060;"test";2629818062
2629827077;"test";2629827079

These values are negative values for Int32

[evgeniym]

Hi Cristian,

Thank you for your reply and for the information provided!
Rest assured that we are already working on fixing this error!
We will inform you immediately as soon as we have a result.

Regards,
Evgeniy

[evgeniym]

Hi Cristian!
Please be informed that we were able to reproduce the issue and fixed it!
This fix will be added to the next build of our product and will be available for all the clients.
Should you have any questions, do not hesitate to ask!

Regards,
Evgeniy

[CristianP]

I tested 9.0.1 and it doesn't work. I doubt it was tested.

In PgClassesUni.TPgSQLRecordSet.ProcessExtFieldsInfo(), Locate2() function will return false because RecordSet.GetFieldAsVariant(Field1, RecBuf, v) will read the OID in the v variable as dtInt32 and not dtUInt32 as it should.
And comparing (v = Value1) will not succeed although binary the values are the same.

[evgeniym]

Hi Cristian!
Please be informed that we were able to reproduce the issue and fixed it!
The fix will be added to the next build of our product and will be available for all the clients soon.
Kindly note that as a temporary solution, until the new build is released, we can provide you with a nightly build of UniDAC which includes this solution.
In order to create this build for you please provide us with your license number and the IDE version you are interested in.
Feel free to send them through the form on our website: https://devart.com/company/contactform.html
Please, let us know if you have any questions!
Regards,
Evgeniy