DSXchange

Hi,

I am creating a job that extacts data from the ODBC. But the desired DSN doesnt appear in the drop down list, whereas that DSN exists and appears Manager. my question is why the DSN list appearing ODBC connection is less than that of Manager.

Girishoak,

in Designer, I think, at the first glance you get only table definitions that have been saved to your repository. There is, however, an 'Import' button in Designer which will display the same DSNs as in Manager. DSNs you want to see here got to have an entry in the uvodbc.config file in the project directory.

Stephan is correct.
The list of DSNs you see in the ODBC stage is obtained from the uvodbc.config file in the project directory on the server. This can be edited manually, but is populated when you import an ODBC table definition.

Hi Stephen,

You are true that we get the list populated only if a table deifination has been saved in directory that to through Manager and not by designer. But if there is no imported table defination, the list will remain blank only irrespective of the DSN entries done in config file. How a normal designer will come to know available DSNs:?: there is only one option remains that is to check the config file. Is there any other option for the same

spracht wrote:Girishoak,

in Designer, I think, at the first glance you get only table definitions that have been saved to your repository. There is, however, an 'Import' button in Designer which will display the same DSNs as in Manager. DSNs you want to see here got to have an entry in the uvodbc.config file in the project directory.

The only two choices are
the import via Manager of ODBC table definitions (you only need to get as far as populating the drop-down list of DSNs) , or
manual edit of the uvodbc.config file in the project directory on the DataStage server

You may find this missing functionality completeless worthless if you parameterize your dsn's, userid's, and password's.

Nothing should be hardcoded (directories, logins, etc) in any design specifically because it complicates the portability of programs (and jobs are programs people) between dev, uat, and prod environments. So this feature, while cute, is not practical. I wouldn't waste time bothering with it.

Now only if they would stop encrypting the password parameter in ODBC/OCI stages, it's tough to check the spelling of "#EDWpassword#" when all you see is "***********".