Hi Jim;

   I suspect that the requirement to now explicitly state the data type conversation is due to PB2022 being based on C++ 2019 VS PB 2017 which was based on C++ 2010. The newer C++ version being more strict of its handling of the ANY data type.

Regards... Chris 

Hi Jim, After you upgraded to PowerBuilder 2022, does it work correctly in client/server mode?  Trying to ascertain if it is a version upgrade issue as Chris mentioned or if it is an unsupported feature of PowerServer.

Hi Armeen and Chris

Apologies - this is a little embarrassing - I checked the SQLDA.OutParmTypes in the PB2017 version and they are also null. I think it must have worked at one time as I did a lot of debugging to get the code working, but that was back in PB6.5

It's also not consistent, as some select statements are returning integer values correctly, which may be due to selecting a column as opposed to a calculation - I need to investigate this further to see what is going on.

I think Chris has probably got the correct explanation for the conversion error occurring, but I should be able to confirm this with further testing

Will get back on this. Thanks for all the suggestions.

Cheers

Jim

Hi Armeen and Chris

The debugger displays the SQLDA.OutParmTypes as null in PB2017, PB2022 and Powerserver. The values are correct in both Powerbuilder versions and the CASE statement operates correctly to set an integer value.. 

Powerserver seems to use TypeString when an integer is returned e.g. "5" instead of 5 resulting in the conversion error.

I've attached HTML of a PSR file showing the 2 versions running and displaying the conversion used.

The code I used is shown below (of_test). It just selects an integer from a table. I modified the app to call it and show the CASE option that executed in a MessageBox

Cheers

Jim

string Stringvar, Sqlstatement
integer Intvar
Long LongVar
Sqlstatement = "SELECT TOP 1 security_level FROM wm_user_profile"
// Sqlstatement = "SELECT COUNT (*)  FROM wm_user_profile"
PREPARE SQLSA FROM :Sqlstatement ;
DESCRIBE SQLSA INTO SQLDA ;
DECLARE my_cursor DYNAMIC CURSOR FOR SQLSA ;
OPEN DYNAMIC my_cursor USING DESCRIPTOR SQLDA ;
FETCH my_cursor USING DESCRIPTOR SQLDA ;
// If the FETCH is successful, the output 
// descriptor array will contain returned 
// values from the first row of the result set.
// SQLDA.NumOutputs contains the number of 
// output descriptors.
// The SQLDA.OutParmType array will contain 
// NumOutput entries and each entry will contain
// a value of the enumerated datatype ParmType
// (such as TypeInteger!, TypeLongLong!, or 
// TypeString!).
CHOOSE CASE SQLDA.OutParmType[1]
		CASE TypeString!
			Stringvar = GetDynamicString(SQLDA, 1)
			MessageBox ('of_test', 'TypeString')
		CASE TypeInteger!
			Intvar = GetDynamicNumber(SQLDA, 1)
			MessageBox ('of_test', 'TypeInteger')
 		CASE TypeLongLong!
 			Longvar = GetDynamicDecimal(SQLDA, 1)
			MessageBox ('of_test', 'TypeLongLong')
		CASE ELSE
			Intvar = GetDynamicNumber(SQLDA, 1)
			MessageBox ('of_test', 'CASE ELSE')
END CHOOSE
CLOSE my_cursor ;

RETURN 1

Hi Jim,

This is a PowerServer bug. We suggest that you submit a ticket through our Support Portal so that it can be tracked properly. You will also be updated when it is fixed. Thanks!

Regards,
David

Hi 

I received the message below in March, but 9835 isn't a link and I can't find details about it and no update to 9842. What it does mean?

Thanks in advance

Jim

Mark Lee @Appeon changed Bug 9482