R98403 and default DB password

Hello,

We are running R98403 job on the enterprise server. It seems to be failing with SQL login. It looks like it is expecting the Table owner and password to be same e.x if the owner is TESTDTA its expect the password to be TESTDTA, else it fails.
This is not how we have our system configured. How can we ensure that the system use our custom password and not the default password while runnign R98403

We are E810 TR 8.96.2.3 on wintel/SQL platform

You can add the following to the jde.ini on the deployment server. Where dsowner is the Data Source owner and dspassword is the password for that owner. Put in one row for each Data Source that doesn't have the default password.
[DSPWD]
dsowner=dspassword
This is changed on the deployment server ini because the apps and bsfns in the list run on the deployment server.

In addition please review solution 200783117 which details the syntax required to change objects owners in SQL 7.0 and SQL 2000

Cheers !!
Lalit Ranka

In your JDE.INI, you can have a section like:

[DSPWD]
PRODDTA=xxxxx
CRPDTA=yyyyy

and this will translate the DB password for the appropriate table owner.

I have to comment though, that R98403 is meant to run LOCAL to the fat client or deployment server, and not on the enterprise server.

All,

Thanks for your reply, However, I am not running this job on the deployment server. My requirement is to run this job on one of the APP servers. I doubt when I run this job on the APP server, it will read JDE.ini from Deployment server.

Then your only hope is to try adding those lines to the JDE.INI of your app server.

Again, I stress that I run R98403 LOCAL from a fat client or the deployment server. In the past, I have had NO luck running it on the server. Given that you are on an Intel platform, this might work, but I have severe doubts.

This sounds like you're trying to use R98403 for something it isn't designed for. Perhaps instead of using R98403 you should consider using a Table Conversion instead to perform the refresh ? A table conversion only takes a few moments to create, and is designed specifically to copy data from one location to another. A table conversion would work well on an application server - and it is possible to either hardcode the ownerID/OwnerPwD into the TC or to use existing tables without creating them initially. One of the most overlooked functions in OneWorld is the CPYTABLE scripting language - it is possible to use this scripting language to create your own "R98403" in just a few minutes. Do some searches on this forum for some of my posts on the CPYTABLE scripting language or CPYSCRIPT.DAT.

Ken/Jon


Thanks for your reply and I fully understand what you are saying.

However, My requirement is to allow end user to copu F0010 table from COntrol table to Business Data. Any thing you write within E1 UBE/TC will only recognize F0010 table based the OCM. It will not read F0010 within the SAME session one from Control table and one from Business Table.

Given the above condition, I felt R98403 with data selection hard coded to run just F0010.

I am going to try to add info to jde.ini and see if it works. if not, then I would have to write it outside E1 ( Simple stored procedure) and Call it from E1 as an external Job

not true. You can copy the F0010 and bypass the OCM using a Table Conversion using a CPYTBLE script. You have to hardcode the from/to Datasource in the Table Design Aid.

Jon,

If I use copy table, Then I need to provide Developer the password for the production Database. Kind of risky. I like the solution, however would need to come up with a solution to hide the password or manually input it.

Hi,

Could you try creating an environment that maps F0010 to Business Data? Use that as your output environment in the TC. Input would be the login environment where you have F0010 mapped to Control Tables.

All,

I used a different strategy to achive this.
1) created a temp table F55...
2) Wrote a simple TC to copy data from F0010 to F55...
3) Created a VIEW prodctl.F0010 which reads data from F55.. IN SQL.
4) Now when OCM is looking for F0010 in Control table, it gets the data by looking at the view, which is looking at the F55... Temp table.

We are running some test to ensure we don't see any problem. Theoritically, we should not see any issues, however you never know

Thanks you all for providing various alternative

Nick,

another "ER programming" alternative would be to use a Table Handle(s). Table handles allow you to change the OCM rules to be used when opening a table. If you setup a dummy Environment that maps the F0010 table to Business Data then you can read from the default table and write to the F0010 copy specified by your "special" OCM rules. Avoids the issues with passwords and platforms altogether.

Think about it.