Multi-member files

[bdisalvo]

Is there a trick for writing a data source to read a particular member of a multi-member file? I have a very old legacy app that I want to convert to Valence, but it is driven by a multi-member file. I could rewrite the underlying structures of the legacy back-end, but I would rather not do that surgery unless necessary.

[robert.swanson]

Is it always going to be the same member name you're going after in that file?

In Valence 6.2 you can set a member name to be applied to all multi-member files in Portal Admin > Settings (default is *FIRST).

You can also activate the "Environment-specific member override logic" setting, then go into Portal Admin > Environments and associate each individual environment with a specific member name to be applied to multi-member files.

member_override.png

[bdisalvo]

Very interesting.
Unfortunately, in this case, the member name is the current user's id.
So, it will vary.

By the way, your portal setting didn't seem to do anything.
(Yes, it is already set to *FIRST)

When I initially wrote the data source sql, I wrote it as:
select * from mylib.myfile
Kind of expecting I would get the *first member for now until I got an answer.

But instead, when previewing the SQL, I got this error:
"File ... must be overriden to a specific member"

[roedea]

You can create an alias to your specific member, do the SQL on that alias, and then drop the alias.

CREATE ALIAS MYLIB.FILE1MBR1 FOR MYLIB.MYFILE(MBR1)

Maybe you can dynamically build it for the username.

[robert.swanson]

Yes, you could create a pre-execution exit program for the data source and dynamically create an alias to the desired member in there based on the user, as Anders is suggesting above. I would suggest first creating the alias in your production library as the "base" and then have the exit program create an alias of the same name in QTEMP, so it supersedes the base. Please reference the Valence Guide for instructions on using an exit program with a data source.


Also, thanks for the heads-up on the "File must be overridden" message you're seeing on the global member default. It's not supposed to do that, we'll get that corrected on the next build. The Environment-specific member override is definitely working properly though.