vscode-ibmi: Can't see sources when opening filters in object browser

@chrjorgensen

Thank you, now it works!

@alfax218

I will look into how we can make this work with SQL enabled. But it may take some time, so in the mean time you may disable SQL to avoid the issue. Is that OK?

Sorry, i made another edit after posted. Even though i can see the sources i can’t open them. In the meantime i think i’m gonna use the version 1.3.10 wich works fine for me (except for deleting filters but i can still delete them in the settings json).

@chrjorgensen

Yeah, letting the database column CCSID control the conversion is also on my mind.

That would be great!

How is your filter doing when you disable SQL in the configuration settings? The extension then uses DSPFD TYPE(*MBR) which returns the member names in CCSID 37 - at least on our systems. Can you check how it affects your lists?

Actually, with SQL disabled it works, i can see both sources:

@alfax218

That’s it - your system has a different CCSID 280 (ITA) for SYSTEM_TABLE_NAME than all my systems, which has CCSID 37 (US). This is the output from my systems:

I also tested this on PUB400, which runs under CCSID 273 (GER) - and it is the same, CCSID 37 for the two columns.

Do you have access to more IBM i systems, where you can do the same check?

We have not done anything special to get CCSID 37 on these columns - installed the system and applied PTF’s using QSECOFR profile. Have you any idea of why your system is different?

@pabloto

I just recreated your scenario on my server - and I get the expected result - with each filter showing one member:

I also tested SQL enabled and SQL disabled - same result.

Please confirm you are running version 1.4.2 of the extension:

Next, try the following:

1. create a new connection - to the same server using the same userprofile and SQL enabled. So we have a fresh configuration with no errors from previous versions of the extension. Not being able to delete a filter indicates you have a corrupt configuration. Verify you see both members in the source file with member filter value ‘*’.

2. Add a filter like the one called TEST123 above - with member filter value ‘§TEST*’. Verify you see one member only in the list.

3. Add a filter like TEST321 with member filter value ‘TEST*’. Verify you see one member only again. Both filters select only one member as specified.

If at any point you don’t get the expected result, please post the output from the Code for IBM i channel.

@chrjorgensen

I’ve edited the reply 1 minute after i’ve posted for more clarity so maybe you’ve missed it. There are 2 members: §test.rpgle and test§.rpgle

@alfax218

If you’re still having problems maintaining your filters, you can manually edit them in the settings.json file:

In the Command Palette type settings and select Preferences: Open Settings (JSON) and search for 'objectFilter'. The member filter is in the member key.

Here is my sample profile:

But be careful - any mistake here may prevent the extension from working!!!

@alfax218

SYSTEM_TABLE_NAME is in CCSID 37 (US) and will never match ‘§’ - but will match ‘@’…

There were a major rewrite of retrieving the member list of a source file in version 1.4.x, and it is now the CCSID on your userprofile, alternatively system value QCCSID, that control how the variant characters ‘#’, ‘@’ and ‘$’ (in CCSID 37) are converted to your national characters.

First, check the CCSID of your userprofile - if it is different from the system value. That could produce a member list with un-expected variant characters.

Next, try removing any variant characters from your filter (when you can edit the filter) and see if you see any members - and what variant characters are shown. You should specify the same characters in your filter as is shown in the member list.

Here is a sample with user CCSID 37 CHGUSRPRF xxx CCSID(37) and member filter MEMBER#*:

And here is the same list, now with user CCSID 1144 CHGUSRPRF xxx CCSID(1144) - I did not change the filter, just the user CCSID:

(The filter did not need to be changed because the ‘#’ is not an Italian variant character - you use ‘£’ instead. So the ‘#’ is not converted and is sent to the SQL LIKE operator as is and thus still match the member name in american (CCSID 37))

When applying any member filter, the filter value is converted from national variant characters to american - to match the output from SQL. You may have to mingle your filter to match what CCSID is on your IBM i user profile. If you change your IBM i CCSID you may also have to change the filters in Code for IBM i - if they contain any variant characters.

Hope this helps…