[SA 9.0.166 Pro] - PostgreSql - no arguments for some func

Which issue do you mean? ODBC related?
I stuck with native connector since it seems to be more responsive. Showing function arguments still doesn't work in 9.0.194.
I executed application update. Should I change something manually?

Edit: yeah.. I can confirm that :OBJECT_ID still contains negative value :(
Guys, It's almost half a year already since it doesn't work properly. I think it's right time to deliver final fix.

Sorry to hear that. I have reopened the ticket. Developers say it's fixed, but I'm not sure if anything needs to be done after the upgrade to 9.0.194 to make it working.

Can you please confirm that you are using factory default queries? I know in the past you tried customizing them to fix the issue. I need to ensure there is no conflict caused by converting returned OID values to BIGINT or some other unexpected datatype.

A simple test on my system SELECT (4123456789)::oid shows the correct value is returned and displayed.

I'm wondering if you had a chance to check your queries for customizations. Can you please confirm you're running factory default queries and still seeing that issue?

Hello. Sorry for delay.. you know, Christmas
Right now I'm on SA 9.0.199 on factory settings. Still no improvement.

I tried to find something on my own.
I modified Objects query, casting all appearances of OIB to BIGINT - No change.
Then I modified Arguments query to just check out a content of OBJECT_ID variable. I did it this way:

	Code:
	SELECT (:OBJECT_ID)::TEXT, (:OBJECT_ID)::BIGINT::TEXT,'',NULL UNION -- original Arguments query right here

See attached screenshot. The OBJECT_ID still contains negative value.

BTW your test case SELECT (4123456789)::oid works for me too. I believe this issue is about how OBJECT_ID is fed with data. I can do some more tests for you. Just give me some scenarios to perform.

Hi. According to the documentation OID is UINT4. Please don't cast it to BIGINT as it would lead to the parameter overflow and potentially to negative numbers. Would you please check that all casting to BIGINT has been removed?
https://www.postgresql.org/docs/9.1/static/datatype-oid.html

As a test, please run a simple query like

SELECT (one of your big kid values)::OID;

Does that query result appear correctly?

This is the point. OID is UNSIGNED INT4 while all postgresql's common numeric datatypes are SIGNED. So, if you treat OID as postgresql INTEGER, then you will end up with negative number if value of OID is greater than 2147483647.

This is why CAST to BIGINT should help (and did AFAIR, if you look at older messages; however it was related to data grid issue).

However, I removed CAST to BIGINT from Objects query, and nothing has changed.
I did run Objects query in Editor, and get proper OIDs:

	Code:
	relname case oid timestamp timestamp get_client_attributes FT 2427107108

Then a few tests for you

	Code:
	SELECT (2427107108)::OID ---- 2427107108 SELECT (2427107108)::OID::BIGINT ---- 2427107108 SELECT (2427107108)::OID::INTEGER ---- -1867860188

Please note, the value from the last test is equal to one shown on screenshot in my previous post

Cast to BIGINT will not help, it will produce 8 byte value while the parameter is expecting and can fit 4 bytes only. Signed or unsigned might be a factor, but again we don't know that for sure, we believe it makes no difference.

Which particular OID value is causing an issues? What do you get when using I with the test query I provided earlier?

I'm sorry I've overlooked the second part of your message. The important part is really here

	Code:
	SELECT (2427107108)::OID ---- 2427107108

So the above query produces correct result. If that's the case, then the issue isn't with parameter values populated by the Objects query. Perhaps an additional data type casting occurs down the road. I will ask our development team to run this particular value through the debugger and check what is then sent to the parameters of the Arguments query and whether the value is byte wise the same (same 4 bytes). I'm sorry it may take a little while. Most of the team is taking a break for holidays.

Yes, this is what I've suspected.
Happy New Year to whole team.

Thank you. Happy New Year to you too!

I will post updates on this issue as soon as they are available.

We would like to give you a private build for testing this particular issue as we don't have a matching environment. We believe we have a working fix, but we need you to test and confirm it. Can we send you an email with download instructions? We have your email, we just need a confirmation that you would like to text that fix.

Yes, please do it.