.Net Framework requires MDAC to be installed on server 2008

My company recently used the tivoli workload scheduler (TWS) to remotely trigger jobs from z / OS to the window server. we verified that tivoli can successfully start mssql services.

Now the problem is that we have the .NET CL program that we used daily to extract some data in the AS400 to the mssql server, it worked fine before using the Windows scheduler and ran daily on a specific time frame. Now we are trying to centralize the scheduler so that TWS remotely runs the prepared batch file (it runs the CL program).

but running the CL program shows the following error when trying to connect to the AS400 database.

.Net Framework data providers require Microsoft Data Access Components (MDAC). Install Microsoft Data Access Components (MDAC) version 2.6 or later.

Edition: in the normal scenario, we assumed that the program could run successfully, it should be the same as using the window scheduler, set the schedule and execute it. the only differences are that the scheduler is not yet a window scheduler, but switches to TWS and runs the CL program remotely. but execution shows the above error while executing the CL program. we do not know why this error occurs. we tried to restart the CL program and schedule it in the window scheduler, it works fine. but the schedule on TWS is remote, an error.

For testing and observation that we have done so far:

  • Our server is a Windows Server 2008 Service Pack 2 (SP2) x64 server, I did some MDAC research used in older versions, while 2008 server should ship with a newer version of MDAC (WDAC 6.0), and it cannot to be reinstalled, so I assume MDAC / WDAC should be installed correctly.

  • the CL program was compiled using .NET 2.0 / 3.0 / 3.5 and tested all of them with the same error.

  • they could write error logs to sql server DB, so I assume that the connection driver used in the CL program has no problems. but this may be caused by the IBMDA400 driver.

  • TWS uses the administrator account on our server to run batch files, the TWS client (listener) is installed on our server to run programs on our server, but we don’t know how they connect to our server (SSH? Telnet?), And they, It seems they don’t actually connect to our server for a remote trigger (starting our work in silent mode).

we are desperate to find any solutions, if anyone can give any hints or thoughts, this will be very useful and will greatly help people with the same problem in the future.

Many thanks!.

+4
source share
3 answers

For these searches, I recently got this error in a web application, despite the fact that MDAC 2.8 SP1 is already installed in the 2008 window. We reinstalled MDAC and it did not seem to fix it. Stopping and starting the application pool for the affected web application resolves the issue. This is not 100% if reinstallation is required, or if updating windows or something required an iisreset that was not there.

+7
source

The reason for this error is that the application pool is trying to read the registry key from the HKey_Current_User hive, which does not always load. The solution is this:

  • Open the IIS Management Console
  • Click Application Pools
  • Right-click the pool for your website and select Advanced Settings
  • Change Download User Profile to True
+3
source

I can only give you several ways to explore.

  • You might want to try using the DB2 iSeries ADO.NET DB2 data provider instead of using the IBMDA400 ODA DB provider. My team had similar experiences when we switched to a new project for the new Windows Server, which was x64. For some reason, we had very strange results when trying to use older OLE DB providers in our Windows .NET services. Later we found out that this is due to the fact that our server was 64-bit.

  • I suspect you have a problem with the IBMDA400 - it is a 32-bit driver. Check if you are compiling the .NET CL program as 64-bit. You can try to compile your program as a 32-bit application and enable Wow64 on your server.

We hope that one of them will lead you to a solution!

+1
source

Source: https://habr.com/ru/post/1414295/


All Articles