We are using a Self-Hosted Integration Runtime for Azure Data Factory.
On that machine there was installed an Exasol ODBC driver of version 6. We wanted to upgrade the driver, deleted an old one and installed a new driver of version 7.
Weird thing is that now in Exasol logs we can see that Data Factory is sometimes connecting via driver version 7, and sometimes via driver version 6.
I made an experiment and deleted Exasol ODBC driver from the machine completely. After that Data Factory still was able to connect to Exasol using the driver I just deleted.
Looks like drivers' DLLs are cached somewhere. What can it be?
Update 1
I captured following actions in Process Monitor when Data Fatory connected to Exasol with ODBC driver of version 6:
Where these C:\Config.Msi\3739be5*.rbfASolution-6.1\ODBC\ DLLs may come from? There is no C:\Config.Msi\ directory on the machine.
Update 2
I noticed that when I test connection via Microsoft Integration Runtime Configuration Manager on the machine or in Data Factory Linked Service, then connection is always performed with ODBC driver of version 7.
But when I test connection via Data Factory Dataset, then in some cases connection is done with ODBC driver of version 6.
You could check the registry but clean at your own risk. An alternative might be the SysIternals tools, Process Monitor or Process Explorer which might help you get to the bottom of this. Install them on the SHIR VM if you are allowed to. Process Explorer in particular is a bit like SQL Profiler (if you've ever used that) so will be able to tell you which registry keys external processes are using. It will give you a lot a lot of information so you will have to make judicious use of timestamp and filtering. The proposed steps:
Start a trace using Process Monitor
Start a pipeline using the Exasol driver
Wait til it completes (or at least you know it has started)
Stop the Process Monitor trace Spend time going through the millions
of records it has captured, trying to filter down, or search for your
process
An alternative would be to build a clean SHIR and install only the new driver. Then swap it in for the old one. You may have to get the new SHIR added to the firewall if this is an issue for you.
Honestly I would propose both of these approached in parallel for a production problem. Procmon / Process Explorer can be quite labour and time expensive but should help you get to the bottom of the issue. Building a cleaner SHIR is probably a safer option in the long-term, but requires new infrastructure.
It may sound silly, but rebooting the server where SHIR is working solved the problem.
We noticed, that this server was running for more than 30 days, and decided to reboot it. Maybe restarting Integration Runtime service itself would also help, but we didn't do it.
Thanks to everyone for you help.
Related
I’m recieving this error when I try to start Cosmos Emulator 2.7.2.0:
Tried it on a fresh win10 machine, and it's working here. Any ideas on what might course this?
I tried all the suggestions in this article.
Looking at the etl file didn't give my anything either.
It's the first time I try to install it on my machine.
-- UPDATE --
I opened the dmp file, and found this:
Loading Dump File [C:\Users\xxx\AppData\Local\CrashDumps\Microsoft.Azure.Cosmos.StartupEntryPoint.exe(1).12596.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 18363 MP (12 procs) Free x64
Product: WinNt, suite: SingleUserTS
18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Debug session time: Mon Jan 20 09:35:26.000 2020 (UTC + 1:00)
System Uptime: not available
Process Uptime: 0 days 0:00:02.000
................................................................
..................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(3134.41b0): Unknown exception - code c000000d (first/second chance not available)
For analysis of this file, run !analyze -v
ntdll!NtWaitForMultipleObjects+0x14:
00007ff9`562fcc14 c3 ret
0:000> .ecxr
rax=0000000000000000 rbx=0000000000000000 rcx=0000003629dfd270
rdx=00000000e6bc7d4e rsi=0000000000000000 rdi=0000000000000000
rip=000000006748b0ec rsp=0000003629dfd190 rbp=0000000000000000
r8=000001ba53134730 r9=0000000000000000 r10=0000000000000026
r11=000001ba6d7662e0 r12=0000000000000004 r13=000001ba6d7974d0
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
msvcr80!_invalid_parameter+0x6c:
00000000`6748b0ec 488d4c2440 lea rcx,[rsp+40h]
Seems like something is wrong with my version of msvcr80
This may be caused by corrupted performance counters on your machine.
To fix your performance counters try the following.
Open cmd as administrator
Run "lodctr /R" (must use capital R)
If this doesn't work, see this link here that shows other options to reset your counters. Older article but works the same on Windows 10.
https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_perf/possible-performance-counter-problem-on-win10/3a5c22cb-1425-4d26-99e7-4ec46940b9a1
btw, one more option here, is to run the emulator in a Docker container. The docs on that are in that article you referenced in your question.
Hope this is helpful.
For me this confusing error message simply meant that I needed to use another port! Or fix problems with the default 8081 one (read update 2 way below).
Here's the text of the error so that it's searchable:
Error: multiple attempts to restart one of the Azure Cosmos Emulator
processes were detected. The emulator will shutdown. If the problem
persist please try uninstalling the Azure Cosmos Emulator, remove the
CosmosDBEmulator directory from your %%LOCALAPPDATA%% and reinstall.
You can also reach out to the Azure Cosmos team using the 'Feedback'
link in the Data Explorer browser window.
Details:
In my case this happened by itself after Windows 10 updated 2004. I swear something breaks in Cosmos DB emulator every feature update!
For me there were no crash dumps and rebuilding performance counters didn't help. In the Event Viewer for System I've noticed this error A LOT:
Unable to bind to the underlying transport for 127.0.0.1:8081. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine. The data field contains the error number.
No solutions for this error helped, so I first used netstat -ao to see if any program is already listening at 8081. Nope.
Then I used the "Port listener" utility from the www, and it turned out it can't listen to 8081 either, not even under admin rights!
Since I couldn't fix this 8081 problem at all & turning off Windows Firewall didn't help, I simply started the Cosmos DB emulator at a different port and it worked!
C:\Program Files\Azure Cosmos DB Emulator>Microsoft.Azure.Cosmos.Emulator.exe /Port=18001
If you've configured cosmos db to be started automatically on system startup, make sure to update that script as well.
In my case this cmdline got me into the Data explorer, but it wasn't actually working. The "Explorer" part of it was "fetching offers" infinitely. I had to again uninstall Cosmos DB emulator, clean this folder: %LOCALAPPDATA%\CosmosDBEmulator, reboot, install again without starting at 8081, and only start at the new port.
Cosmos DB devs, you're awesome people, but this is too much hassle. And if you can't use the port just say so, you don't have to be cryptic!
UPDATE:
This worked, but I forgot to update the start up script to use the new port, and noticed that after one more reboot the cosmos db started on 8081 without issues. What??! But it wasn't just any old reboot - I already did several of them before and they didn't help. This reboot may have been special in that it came after Windows found one more update (kb4576478), probably realizing it's now needed since I'm at version 2004, installed it, and THAT reboot (or the kb4576478 update specifically) fixed the 8081 problem, whatever it was. Yikes!
UPDATE 2:
Had another port-related problem with another tool. Ugh. Found this solution (see "General workaround") https://superuser.com/a/1568476/251491 This page's accepted answer also mentions the magic of multiple reboots.
Finally got it working!
By using WinDbg and opening the dmp files %LOCALAPPDATA%\CrashDumps, I found out that a dll called perf-MSSQL$SQLEXPRESS-sqlctr10.1.2531.0.dll was the root cause.
By deleting this in the %WINDIR%\System32 the error was "fixed" and I can now run the emulator.
I am trying to install Teradata connection in a virtual machine of Windows Server 2012.
I tried multiple times but I still got the timed out error: No response received when attempting to connect the Teradata error.
I tried connecting through SQL assistant and python teradata module. Below is what I have tried based on resolutions found on web search and none of them works
1. Close the firewall
2. Change the odbcLibPath (in Python)
3. Reinstall .NET framework
4. Extend the time awaiting for response
5. Seeking resolutions around odbc.ini and odbcinst.ini but for Windows specifically, I can not find any resolution.
I have also not be able to find much difference between the configuration on the virtual machine and that on my local desktop which works well.
I felt I have run out of possible solutions at the moment. Appreciate any help in this.
We have code to connect to various databases and we get the driver version after connecting using the SQLGetInfo() call with the parameter SQL_DRIVER_VER.
However, we want the driver version in other cases too, e.g., before connecting, and in case of an error on trying to connect. The only way to get the driver version in these cases at least on Windows seems to be via the file metadata information of the driver DLL. The drivers on other platforms do not even have this file metadata.
So, is there a way to get the driver version using ODBC when we are not connected?
Thanks,
Ed
The ODBC API doesn't support this interrogation until the connection is live.
There are tricks you can bring to bear, such as those used by the iODBC Administrator.app on OS X. You might look into that source code.
We are running an AS400 v5r2 and I have iSeries Client access installed. Since v5r2 does not support a x64 ODBC driver does anyone know how I can either install two versions (v5r4 supports x64) of iSeries Client Access on the same box or just install the x64 odbc driver from the more recent version without uninstalling all of v5r2 components.
Installing two versions of Client Access is probably not going to work, since both register their ODBC drivers with the same name, so only one would be available at a given time.
OTOH the PC side of V5R4 Client Access would probably work without problem with a V5R2 OS/400; perhaps even 6.1 iSeries Access, too. So you can upgrade the x64 box and check whether everything is working. FYI, I had problems with the first versions of 6.1 iSeries Access when running on x64 boxes, later versions were a bit better; also, I do not remember that V5R4 Client Access had a 64-bit variant at all.
Do not forget that on a x64 PC, there are two different ODBC drivers, one for 32-bit applications (stored on C:\WINDOWS\SysWOW64\cwbodbc.dll and that you can manage with the 32-bit administradorC:\WINDOWS\SysWOW64\odbcad32.exe), and another one for 64-bit applications (stored on C:\WINDOWS\System32\cwbodbc.dll and that you can manage with the 64-bit administrador C:\WINDOWS\System32\odbcad32.exe.) Unless your application is recompiled for 64-bit, what you are interested in is the former one, and if V5R2 Client Access runs flawlessly on that PC, everything is fine. Some applications like Office 2010 come in two flavours, but precisely for compatibility reasons like ODBC, it is still recommended to run the 32-bit variant even on 64-bit workstations.
1) V5R2 is very dead. You aren't going to get a lot of help when it comes to supporting an OS this old.
2) V5R4 is also dead.
3) Generally speaking, IBM intends that Client Access will work for operating systems two levels back and two levels ahead, so you could try using a V5R4 ODBC driver against a V5R2 DB2. The issue is going to be getting a V5R4 version of Client Access.
4) If you have questions about admin issues like this, Server Fault is probably the better choice.
EDIT: Add details of Client Access installation
Client Access has two logical pieces, a server side component and a client side component. Both pieces are available in the IFS, in the QIBM directory tree. If you have an already-working setup of Client Access on the server side, you can install the client side one of two ways:
1) Map a network drive to the IFS and run setup from there. This obviously won't be helpful to you because the V5R2 software doesn't support x64. If you are still under software maintenance, you could order a newer version of Client Access and install it on the server, and then use the newer version to install the needed ODBC driver.
2) Use the IBM-supplied CD to install the client component directly on the client. This allows you to install a different client version than the one on the server. Not generally recommended but in the case where you're migrating away from an unsupported machine, it's probably not a big worry. If your company ordered V5R4 at any time, you have the Client Access CDs.
The key thing for you is that you don't need to install the full Access product if all you need is the ODBC driver.
The biggest problem facing you is the age of the software. IBM stopped supporting V5R4 in Sep 2013. You aren't going to be able to place an order for it with IBM. You might be able to order V6R1 but the ODBC driver may not work with V5R2 - you'd have to try it. See the IBM i Access web site for details, but it's not downloadable.
If you can use OLEDB, try IBM's FTP site.
I have been given an ad hoc reporting tool from another individual that has successfully deployed it to the field. He uses Web Logic servers and an Oracle database.
I tried to deploy the same application in my local environment (WAS 7 and Oracle). The first report runs flawlessly. However, when I run the second (or third or fourth) report, I get a very strange error: the second report is appended to the first report.
There is nothing in the code to account for this. This problem can be temporarily solved by stopping and starting the servers every time a report is run (obviously not a real solution). I think this has something to do with data sources and cached information. I then took a step back and tried to deploy it to a Tomcat server. It works perfectly, just like it does in the field. So my question is: are there any known issues between WAS 7 and Oracle 11g that could be causing this kind of problem? Any information would be very helpful.
Please ask about any specifics you may want to know and I will do my best to provide that information.
Thank you for your time.
EDIT: For anyone else looking into this, the problem was due to an incompatibility with the proprietary Oracle calls and Websphere. Once the application was edited to use only JDBC calls, everything works perfectly. Thanks.
This ended up being a incompatibility with using proprietary Oracle calls and Websphere. It was fixed by changing all of proprietary call to normal JDBC calls.