.Net framework require MDAC installed in server 2008

Question

My company recently using tivoli workload scheduler (TWS) to remote trigger jobs from an z/OS to window server. we have tested the tivoli can trigger the mssql services successfully.

The problem now is we have a .NET CL program that we used daily to extract some data in AS400 to mssql server, it was worked perfectly before when using windows scheduler and trigger daily in specific time frame. now we trying to centralize the scheduler so the TWS remotely trigger a prepared batch file (it will trigger the CL program).

but the execution of the CL program show following error while trying to connect to AS400 DB.

The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later.

EDITED: in normal scenario, we were assumed the program can trigger successfully, it should be just like using windows scheduler, set a schedule and execute it. the only differences is the scheduler is not windows scheduler for now, but switch to TWS and trigger the CL program remotely. but the execute show the above error during executing the CL program. we have no idea why this error comes up. we tried to rerun the CL program and schedule it in windows scheduler, works fine. but schedule on TWS remotely, error.

For the testing and observation we have done so far:

1. Our server is Windows server 2008 SP2 x64, I have made some researches the MDAC used in old version windows while server 2008 should deliver with a newer version of MDAC (WDAC 6.0) and it cannot be reinstall so i assume the MDAC/WDAC must be install correctly.

2. the CL program was compiled with .NET 2.0/ 3.0 / 3.5, and tested all of them produce the same error.

3. they error logs were able to produce to sql server DB, so I assume the connection driver using in CL program have no problem. but it might be caused by IBMDA400 driver.

4. TWS use the admin account in our server to trigger the batch files, a TWS client (listener) is installed in our server for trigger programs in our server, but we dont know how they connect to our server (SSH? telnet?) and they seems donot actually login to our server for remote trigger(trigger our job in silent mode).

we are desperate in seeking any solutions, if anyone could provide any clues or thoughts, it would be very helpful and provide a big help to the people with the same problem in the future.

Thank you very much!.

Sanative

Is there a question inside your posting? I've double-read but cannot find what you want to know. – Scrag

Answer 1

For those searching, I recently got this error in a web app despite MDAC 2.8 SP1 being already installed on the 2008 box. We re-installed MDAC and it did not seem to fix. Stopping and starting the app pool for the affected web app fixed the problem. It's not 100% clear if the re-install was necessary, or if windows updates or something required an iisreset that didn't happen.

Cohlette

This was helpful, thanks. With that said, I was unable to resolve the issue until I restarted IIS as a whole, not just the application pool. – Hardunn

Recycling the application pool either create or fix the problem. I found that link: Mystery of MDAC Not installed error. Which explains really well what could cause it. As stated, setting "Load User Profile" seems to fix that. – Fought

We got the same error, and restarting the app pool worked fixing this error for us. Also fixed a few GDI errors. – Langdon

Answer 2

The reason for this error is that the application pool is trying to read a registry key from the HKey_Current_User hive which isn't always loaded. The solution is as follow:

1. Open IIS management console
2. Click on "Application Pools"
3. Right-click the pool for your web site and select "Advanced Settings"
4. Change the setting "Load User Profile" to True

Asiaasian

Answer 3

I can only give you some avenues to investigate.

1. You may want to try using the IBM DB2 iSeries ADO.NET Data provider instead of using the IBMDA400 OLE DB provider. My team had a similar experience when we went through a re-platforming project to a newer Windows Server that was x64. For some reason we had very strange results trying to use the older OLE DB providers on our .NET Windows Services. We later found out it was due to our server being 64bit.

2. I am suspecting you are having an issue with the IBMDA400 is a 32bit driver. Check if you are compiling your .NET CL program as 64bit. You could try to compile your program as a 32 bit application and enabling Wow64 on your server.

Hope one of these leads you to a solution!

Baudelaire

Application Pool Recycle is enough – Belize