Hi Narayanamoorthy,

Try performing a full build and optimize of each library. That might be able to solve the problem. 

Some of you objects could have gotten corrupted. The full build and optimize might be able to help.

Regards,

Greetings, Narayanamoorthy - 

Can you please post the exported source for primary DataWindow and the impacted Drop-Down DataWindow objects, for both languages, if there are different ones for each language. I'd prefer to have the .srd files zip'd and attached in a new post instead of pasting the exported source, as I'd like to examine them in an editor. Remove the majority of the SQL SELECT statement(s) if you have concerns about security...I want to see the column datatypes, DataWindowChild configuration and other options.

What DBMS are you using, and what SQLCA.DBMS (driver) setting?

Specifically, how are you switching languages? Can you please describe what occurs "under the covers" when this is requested?

Regards, John

In going from such an old version I wouldn't be surprised if it were not related to a 'GetChild' datawindow method call.  Have you looked at the script relating to these columns and how they are being populated?

Just a thought...

Hi,

Appeon will provide the premium support for the above issue to get it resolve? If yes. How should i approach.

Br,

Moorthy

My original offer to help you troubleshoot your issue is still valid, but you've not answered any of the questions I posted in my earlier response.

This is a question & answer forum, not a support portal. That's why I am unable to meet with you online The people in the Q&A forum of the Appeon Community try to the best of our abilities to answer the questions that have been posted, but often we need additional information - so we ask follow-up questions. 

It should be obvious that there have been a LOT of changes made to PowerBuilder since version 6.5 that have had a major impact on the product, such as switching from ANSI (single-byte/character) to Unicode (two bytes/character) strings internally, support for newer versions of Windows, support for new versions of RDBMS's, even new database vendors, REST services, etc., so even though YOUR code and/or your DataWindows may not have changed, there has been a lot that has changed under the covers. This may have and evidently has made something in your application work differently than it did previously under version 6.5.

You've still not yet told anyone in this thread what database (vendor, version, character set(s)) you were using under PB 6.5 and what database you are using under PB 2017, so I don't know how you expect anyone to be able to assist you under these circumstances. A test case, example DW's used for the drow-down/child DW and the main/data entry DW would be extremely helpful. regardless of whether you would like the (free) Community to help or the (paid) Appeon Premium Support.

The choice is ultimately yours, but I feel you have not yet fully utilized the expertise and talents available to you here and I encourage you to do so... but you need to meet us halfway.

1.  Can u check whether the data column and display column of the dropdown datawindow haven't got modified between 6.5 and 2017.

2.  Whether the data (code value(name) could be read for the code that's get displayed from a test datawindow.  aka whether data exists in the database for the code.

my 2 cents

Happiness Always
BKR Sivaprakash

Hi John,

Both window and data window file attached here.

Hi,

Below are the fileds getting updated code instead description.

Ratkaisu - ratkaisutyyppi
Tot.tapa - liittymatyyppi
Tap.laji- tapahtumalaji
Resepti - reseptitunnus

What is the name of the DataWindow Control in the window?  --->d_tilliittyma

Can you please post the exported source for the drop-down datawindow(s) used by these columns? --> Can you tell me how i can take the specific columns source details from datawindow?

For reference image.

From examination of the exported datawindow source code, I see the following:

Column id 96: ratkaisutyyppi  char(8)
DDDW name: d_pop_koodi  DisplayColumn: kuvaus  DataColumn: poptunnus  DDDW.limit = 0

Column id 16: liittymatyyppi  char(8)
DDDW name: d_pop_koodi  DisplayColumn: kuvaus  DataColumn: poptunnus  DDDW.limit = 40

Column id 11: taphtunalaji  char(8)
DDDW name: d_pop_koodi  DisplayColumn: kuvaus  DataColumn: poptunnus  DDDW.limit = 40

Column id 26: resepitunnus  char(8)
DDDW name: d_muko_koodi  DisplayColumn: nimi  DataColumn:  koodi  DDDW.limit = 40

Since I do not have the source for d_pop_koodi and d_muko_koodi, I can only assume the columns identified as the DataColumn are also defined as char(8). That is one item I suggest needs to be checked.

I'm not sure why the dddw.limit is not the same for these columns. Another thing you could experiment with.

I suspect there may be a problem with the changes being made at execution time to switch languages. Since you have functions in global objects dynamically making significant changes to the main datawindow, I suggest you temporarily add a command button to the window that extracts and displays the dddw.displaycolumn and dddw.datacolumn properties of each of these four column objects... This can be done via dot notation:

String ls_displaycolumn, ls_datacolumn
ls_displaycolumn = d_tillittyma.Object.ratkaisutyyppi.dddw.displaycolumn
ls_datacolumn = d_tillittyma.Object.ratkaisutyyppi.dddw.datacolumn

or via Describe:

String ls_displaycolumn, ls_datacolumn
ls_displaycolumn = d_tillittyma.Describe("ratkaisutyyppi.dddw.displaycolumn")
ls_datacolumn = d_tillittyma.Describe("ratkaisutyyppi.dddw.datacolumn")

Then display these values (along with the column name) via MessageBox. I'm not familiar how this app works, but if possible, check these values before and again after switching languages.

The only other suggestion I have is to temporarily disable the dynamic property changes to these columns, if possible, to see if the errant behavior clears up. That might indicate or give a clue where the issue lies.