Related
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.
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.
I have some questions:
Is it possible to install openstack on a Notebook with a 4GB DD3 Ram? Because the website says it needs atleast 8GB of RAM.
They say it requirs a double-QuadCore , I assue that means Octacore. Can we install that on a Quadcore?
They say that there is no possibility to install it on a NAS . Did you find any where if there is a possibility to do?. I dint find any even after asking our friend(google).
All in all, is it at-all possible to install on it a notebook/Desktop?
That advice is for production environments,
so 1)If you just want to play around your notebook will do fine. I had a succesful test-run on a 1.2 Ghz 1GB Netbook. It became incredibly slow when it launched it's first instance...
With a Double Quadcore they actually mean two seperate Quad-cores, as in two quad-core xeon processors on a single motherboard
So 2) yes you can install it on a quad-core.
3) a NAS device running openstack an openstack storage service seems to be unlikely indeed. You will most likely need more computing power.However If your NAS supports NFS or SSH or sth you can probably mount this drive and use it for storage.
4) You can perfectly build a all-in-one openstack test setup on your notebook. Performance will be low, but acceptable for testing.
It depends on what you mean by "install OpenStack". OpenStack itself is an extremely modular framework consisting on many services (Compute, Networking, Image service, Block Storage, Object Storage, Orchestration, Telemetry, ...). On top of that, a typical production deployment of OpenStack also requires several components, like load balancers, caching systems, firewalls, web servers and others. It is definitely possible to install a minimal openstack system, even on an average laptop.
The simplest way to run OpenStack on a laptop/desktop is to use Devstack, a shell script that installs all services from source and run them (by default) on a single machine. It is customizable enough to provide very good testing ground; it's used by OpenStack developers as well as the OpenStack QA team to test latest developments against "real" systems.
To avoid messing up your system, it's generally recommended to install OpenStack in a VM. From devstack doc:
DevStack should run in any virtual machine running a supported Linux release. It will perform best with 2Gb or more of RAM.
As of the time of this writing (Jan 2015), supported distros are:
Ubuntu (latest LTS)
Fedora
CentOS
Regarding NAS: you can of course use it, but "outside" Openstack apis, by providing mount points to your vms. It's even mandatory if you want to support live migration.
I've installed parallels desktop on my MacBook to be able to run Visual Studio 2008 in a XP installation. Everything works great except when I decided to put my websites in my sites folder in the os x file system (Which by default automatically happens because the My Documents folder is mapped to the Mac's Documents folder, and I'd rather put my code there so that both OS's can easily access it.).
When trying to build or debug I get this error:
Failed to start monitoring changes to 'Z:\xxx...'
How do I get it so that I can get it to work under Parallels, from the shared drive?
Parallels uses network drives to simulate folders on OS X, and Windows can't monitor changes to network drives, so if you do this directly, it'll be broken.
If you want to keep them in sync though, use Live Mesh (http://www.mesh.com) and install it on both the host and guest. A little roundabout, but it'll make it so both copies are maintained (and Live Mesh is handy for other things too)
I recently flipped over to putting my source code onto my Mac volume, so I could use Time Machine to back it up and immediately got this same problem with my ASP.NET app. Other, procedural applications, built just fine, by the way.
I tried all sorts of things, including using Samba on the Mac side to share the directory, which led into the "too many BIOS commands" error described elsewhere. Unfortunately for me, the Registry hacks to fix that problem never worked for some reason.
I finally found another solution that avoids Samba and just uses the regular Parallels Shared Folders. It too is a Registry hack, but this one simply turns off file change monitoring for ASP.NET. It is a bit heavy-handed, but gets my builds to work again.
The reference for this change is here:
http://support.microsoft.com/kb/911272
The downside to this approach, I am finding, is that you need to be more deliberate about recompiling, or restarting the web server, as changes during development don't just magically appear anymore. I am still deciding whether that is a useful tradeoff.
UPDATE: After several days of this, development was just too difficult and, sadly, what I reverted to was keeping my source inside the Parallels virtual disk. To enable Time Machine backups and Spotlight searches, I used a lightweight MS utility called SyncToy to push stuff out of Parallels and out to my Mac drive several times a day. Despite the high hack factor, it is working well.
I know this isnt strictly a solution but VMware fusion is superior when it comes to shared drive space on a virtual machine. Its what i currently use and hasn't let me down thus far...
People always give me odd looks when they see visual studio on my mac :P
Try moving the project on to the VMs C drive. Its not an ideal situation, but you can access the VMs C drive from OS X.
I have a similar problem with a php site that uses an MS Access database (its a clients system). I have alias's that point to the php site on the VM so that I can still do all of my coding in OS X. To do this I created a network share on the VM and then connected to it from OS X. Once connected make the alias's. If the network drive is not open and you open a file in OS X it will try to reconnect. It means the VM will need to be running to get to the files, but this isn't normally a problem since the VM is hosting the site anyways.
.NET has funny issues trying to debug the objects on a network drive.
make sure that you have full trust on your local network between your Mac and XP install.
Check out: http://msdn.microsoft.com/en-us/library/aa302361.aspx
If at the end of that research, I"m afraid you will have to look into the option of keeping it on the VMDisk and moving it when you need it.
I see a similar problem on my machine connected to the windows domain. My documents is mapped to a network share and I can't debug|run|etc. I had to eventually move to my local disk for debugging.
I definately recommend Live Mesh as a way to keep directories in sync. Just keep the VM's directory in sync with the Mac's directory.
Or use SVN to hold copies in both machines and do commit/update as appropriate. That way you get versioning, history and if your project grows bigger, you can share with other devs.
I know dropbox also has history and sharing, but not check in/check out/conflicts and all the other advantages of a real source control.
Oh, if you have money you can also go for TFS. I would but it is just too expensive :)
When I try to connect to local ports, Computer -> Connect local, using Portmon v. 3.02, I'm getting an error message, Error 2, in a small error dialog box:
I run the tool as an administrator (if not, I get error 6).
By the way this is a Windows 7 x64. On 32-bit, in Windows 7 x86, it works fine. How can I fix this problem?
Sysinternals' Portmon works only on 32-bit versions of Windows. It does not support 64-bit (probably its driver is not signed).
From the Portmon homepage:
Runs on:
Client: Windows XP (32-bit) and higher (32-bit).
Server: Windows Server 2003 (32-bit) and higher (32-bit).
In Windows Explorer, right click on portmon.exe --> select Properties --> click the Compatibility tab, and Run in Windows XP compatibility mode. It works fine like that in Windows 7 64-bit.
"Error 2" is "Cannot find the file specified", that is, cannot find a required DLL file.
Originally, you got this error when you tried to run Portmon from a network location: that broke the security trust, causing Portmon to be untrusted (or perhaps just messing up the search path somehow).
On my copy of Windows 7 64 bit, Microsoft Dependency Walker (depends.exe) tells me that PORTMSYS.SYS (the file created/loaded by Portmon.exe), has unresolved dependencies on ci.dll, clfs.sys, hal.dll and kdcom.dll.
Those are the
code integrity
common log file system
hardware abstraction layer
kernel debugger com
libraries, and they aren't actually missing: if they were, Windows wouldn't boot. However, I don't see a copy of those files in SysWow64. This suggests to me that the problem is not with portman.sys: the problem is with the win32 compatibility layer in Windows 7/64 bit: It doesn't support debug properly.
It is now 2018. There is no 64-bit version of Portmon. Serial ports are a legacy standard. The Windows 7 problem was fixed by the release of Windows 8.1. However, there is a faint chance that some Visual Studio utility or security update back-ported to Windows 7 will fix the problem. Perhaps someone who is familiar with SysWow and debugging will comment.
Instead of portmon for Windows x64, you can use an emulator of a pair of virtual COM ports and a simple program that will connect the physical port and one of the virtual ones, as well as perform the logging function.
To create a pair of virtual COM ports you can use:
com0com (preferably version "com0com-2.2.2.0-x64-fre-signed", because it contains signed x64 driver)
Virtual Serial Ports Emulator (VSPE), every time it starts on x64 it asks to purchase a driver, but it works even if you refuse.
Simple mapping and logging program can be found e.g. here or you can write it yourself, it is simple.
The sequence of actions is follows:
Сreate a pair of virtual COM ports using emulator (for example, COM28 and COM29)
Let the external device be connected to the computer COM1 port. In the program, whose exchange with external device we want to listen to, we set up a port COM28 (instead of СОМ1) for communication.
In the mapping program, we set up that we want to bind and log ports COM1 and COM29 (don't forget to set the port baud rate).
I haven't tried it yet, but this question mentions com0com. It creates two virtual serial ports and emulates a null modem cable between them. It claims to be able to run on 64 bit Windows. I'm not sure whether it comes with software that lets you just pipe input from a real port into one of the virtual ports. One of the FAQ's says that you can turn on logging.
I guess in the worst case, you could write your own small program that pipes data from a real port to one of the virtual ports and logs it all.
There's also this question on open-source alternatives that mentions a couple of projects.
I've used AccessPort
http://sudt.com/en/ap/download.htm and it works great. Very similar to Portmon
Don't start Portmon from a network drive/path or something else.
Copy on to the hard disk drive, e.g. on the desktop, restart and try again!
If you run Portmon in compatibility mode, it will work.
Check Make older programs run in this version of Windows.
It says:
To run the Program Compatibility troubleshooter:
Open the Program Compatibility troubleshooter by clicking the Start button Picture of the Start button, and then clicking Control Panel. In the search box, type troubleshooter, and then click Troubleshooting. Under Programs, click Run programs made for previous versions of Windows.
Follow the instructions in the troubleshooter.
The above is a public explanation from Microsoft for a common situation when running older applications in Windows.
But, I can say it briefly;
Right click on portmon.exe
Select menu about "troubleshooting compatibility problem" or something like that (I'm using a foreign version of Windows, so I don't see correct name of that menu in English.)
Select automatic mode
It will detect the problem and recommend Windows XP (SP2) mode
Select it and execute Portmon again.
I hope it works!
Instead of Portmon you can also use the IO Ninja program with the "Serial Monitor" plugin.
It gives a little less information than Portmon, but in a more understandable form. The main thing is, just like a Portmon, it allows you to see the data that is transmitted between a third-party application and an external device via a serial port. The program works under modern versions of Windows (I tried it myself on Windows 10 x64). The aforementioned plugin "Serial Monitor" is paid (but has an evaluation period).
Note: the port that you want to monitor must first be connected to the "IO Ninja" program, and then opened in a third-party application whose exchange with an external device you want to track.
Just to test that the hardware is working, you could perhaps boot a Linux live CD and run the statserial and/or minicom program to verify that it works. The Knoppix distribution seems to contain both those programs.
Serial ports on Linux are named /dev/ttyS0 for COM1, /dev/ttyS1 for COM2, etc.