I need to test one odbc driver for mac.
What are database query utilities using ODBC for Mac OS X like DBForge, OmniDB etc?
Presuming you are testing a driver bound to iODBC, the ODBC driver manager that Apple ships with macOS, you should install the latest iODBC SDK update, which comes with iODBC Test.command and iODBC Demo.app (found in /Applications/iODBC/). You can execute any arbitrary ODBC query through these tools.
ODBC Bench, a separate install which simulates TPC-A and TPC-C on your own equipment/network. (You'll need to build your own binary to test a 64-bit driver, as the downloadable pre-built binary is 32-bit only.)
Most GUI-space apps on macOS are shipped with binding to iODBC, and are thus also candidates for your use.
Related
When trying to make a program on Windows that connects to a database via ODBC, I got the following error:
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
I'm sure my code is right. It even worked on a different PC.
Why am I getting this error? And How do I fix it?
What causes this error?
The error message tells you, simply put, that the ODBC Driver Manager could not find the driver you specified in your connection string or DSN.
This can have 3 common causes:
The driver you tried to use is not installed on your system
The driver is installed, however, it doesn't match bitness of the code you're running
You made an error in typing the driver name
How do I check which drivers are installed on my system?
You can check the drivers which are installed on your system by going to the ODBC Data Source Administrator. To open it, press ⊞ Win + R, and type in: odbcad32.exe. Then check the tab Drivers for installed drivers. The Name column indicates the exact name you should use in your connection string or DSN.
If you're on 64-bit Windows, that only lists the 64-bit drivers installed on
your system. To see which 32-bit drivers are installed, press press ⊞ Win + R, and type in: C:\Windows\SysWOW64\odbcad32.exe, and go to the Drivers tab again.
The driver is installed, but it might be the wrong bitness, what do I do?
Then, you have two choices, either adjust the bitness your program is running in, or install a driver with a different bitness.
Some of the drivers that are installed by default on Windows only have a 32-bits variant. These can't be used with 64-bits programs.
You can usually identify which bitness a program is running under in task manager. In Windows 10, all 32-bit programs have (32-bit) appended to their name. If that isn't there, you're likely running a 64-bit program, and most modern programming languages and environments run on 64-bit by default, but allow you to switch to 32-bit. However, the specifics for different programming languages are outside the scope of this question.
How can I verify I didn't mistype the driver name?
An ODBC connection string looks like this:
DRIVER={DriverName};ParameterName1=ParameterValue1;ParameterNameN=ParameterValueN;
The driver name part needs to be delimited by curly braces if it might contain special characters, and needs to exactly match the installed driver name, as found in the ODBC Data Source Administrator, including spaces and typographical characters, but excluding capitalization.
Note that for deployed code, the driver must be present on the computer/server running the code.
I don't have the driver, or have the wrong bitness, where do I get the right one?
That depends on which driver you want to use.
A list of common drivers with download locations (all 32-bit and 64-bit at the same URL):
The Microsoft ODBC Driver 17 for SQL Server
The Microsoft Access database driver, which is part of the Microsoft Access Database Engine. Note that simultaneous installations of 32-bit and 64-bit Access ODBC drivers are not supported.
The MySQL ODBC connector by Oracle
The open-source SQLite ODBC driver by Christian Werner (non-official)
psqlODBC, the official PostgreSQL driver
If the driver you want to use isn't listed, the location is usually easily found using Google.
In design mode, a value has been set to the property of
TFDConnection.ConnectionDefName must be empty.
I'm working on a project which uses the D2XX drivers from FTDI chip.
We are delivering the ftd2xx.dll file as part of our application. As far as I understand, the other files (e.g. ftdibus.sys) are installed on the system (at least for Windows) where the application runs. Linux is also a target for us, but let's ignore that for simplicity now.
My question is regarding the relation between these files? If, for example, I upgrade the ftd2xx.dll file delivered with our application, will users have to install the newest drivers? What if they do not?
In addition to the specific FTDI drivers, any general source of information on this area is also very welcome.
I used to work on a project that made use of FTDI's D2XX library.
There is no tight coupling between the exact version of ftd2xx.dll and ftdibus.sys. I believe the interface between ftd2xx.dll and the kernel mode driver is version independent at the basic feature level (at least since version 2.04.06 or so). There is even functions in the DLL to query DLL and driver versions respectively.
Thus, it can happen that they are 'out of sync'. I.e. ftd2xx.dll could be one from a more recent release than ftdibys.sys or vice versa. That is not a problem as such.
You are of course in complete control of the ftd2xx.dll version, but how does the driver package get installed? Is it installed as part of your application, or do you rely on the user obtaining the driver from another source? If your application has an installer, it could be an option to include FTDI's driver package in the installation. Thereby you will know which driver version is available.
What can be really tricky (and what has caused me headaches) is if there are other devices on the PC that use FTDI's chip. If such a device is supplied with media containing an older version of the driver and the user chooses to install this driver, it will simply overwrite any existing version of the driver (e.g. the version that your installer provided). This is a potential cause of regression, because FTDI has resolved a lot of bugs in the driver over the years.
If I were you, I would check the driver version at runtime and compare it to a version that is known to work (the version that you tested your application with). If the driver is older, suggest the user to upgrade it. Otherwise I would assume it is compatible.
We have a device that requires we install drivers before it's plugged in, otherwise we need to remove the drivers that Windows 8 and 10 automatically download.
How do we make a USB driver installer that can install correctly whether it's plugged in first or not?
On Windows 10, my simple driver for usbser.sys with just an INF file and a CAT file will automatically take precedence over Microsoft's usbser.inf that they supply in Windows 10. But if that doesn't happen for your particular driver/device, you might look into using DevCon, an open source utility from Microsoft that can be used to list devices and update their drivers. I have never used DevCon in an installer, but I think I have noticed other installers that use it. There is an MSYS2 package for DevCon.
We use DPinst which is a Driver Package installer program that Microsoft supply. It is quite flexible & straightforward to use & can give you a pretty standard wizard UI.
I am using Libre Office Version: 4.3.4.1 on my Mac OSX 10.10 Yosemite.
In Base Database, I would like to connect MS-SQL server using unixODBC DSN.
But it seems the Libre Office tries to connect via iODBC, not unixODBC.
(I never installed iODBC on my Mac.)
Here is what I tried.
Following instructions, I already setup unixODBC, FreeTDS using Homebrew and all the tsql/isql connection tests were fine.
After installing, I launched "Database Wizard" from Base database.
And choose 'ODBC' from "Connect to an existing database",
I entered s01, my unixODBC DSN name, to "Name of the ODBC data source on your system" field. (When I clicked 'Browse' no registered data source were shown.)
And I typed my unixODBC username and checked Password required.
When I clicked 'Test Connection' button and input the password, an error occurred as below.
[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded.
SQL Status: IM002
[iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded
Does anyone have an idea to solve this problem?
I would recommend you stick with iODBC, the ODBC driver manager Apple has shipped as part of OS X since Jaguar (10.2). The version Apple bundles into Yosemite (10.10) remains a bit behind, at 3.52.6, so I would also recommend you update to 3.52.10.
iODBC and UnixODBC are built to be API equivalent, so you should just need to ensure that your drivers and DSNs are properly configured in the iODBC locations, optimally via iODBC Administrator.app (/Applications/iODBC/). System DSNs are recommended for most purposes.
/Library/ODBC/odbc.ini # System DSNs
/Library/ODBC/odbcinst.ini # System drivers
~/Library/ODBC/odbc.ini # User DSNs
~/Library/ODBC/odbcinst.ini # User drivers
I heard that it has been ported to multiple virtualization platforms and switching chipsets? what does the virtualization platforms and switching chipsets mean here? what is the difference between them?
another question is :can we install the openvswitch on the bare metal switch or router?I mean can we install it on just hardware without any operating system?
From OVS FAQ, which is readily available with a Google search:
Q: What virtualization platforms can use Open vSwitch?
A: Open vSwitch can currently run on any Linux-based virtualization
platform (kernel 2.6.32 and newer), including: KVM, VirtualBox, Xen,
Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
mainline kernel. The bulk of the code is written in platform-
independent C and is easily ported to other environments. We welcome
inquires about integrating Open vSwitch with other virtualization
platforms.
Q: How can I try Open vSwitch?
A: The Open vSwitch source code can be built on a Linux system. You can
build and experiment with Open vSwitch on any Linux machine.
Packages for various Linux distributions are available on many
platforms, including: Debian, Ubuntu, Fedora.
You may also download and run a virtualization platform that already
has Open vSwitch integrated. For example, download a recent ISO for
XenServer or Xen Cloud Platform. Be aware that the version
integrated with a particular platform may not be the most recent Open
vSwitch release.
Q: Does Open vSwitch only work on Linux?
A: No, Open vSwitch has been ported to a number of different operating
systems and hardware platforms. Most of the development work occurs
on Linux, but the code should be portable to any POSIX system. We've
seen Open vSwitch ported to a number of different platforms,
including FreeBSD, Windows, and even non-POSIX embedded systems.
By definition, the Open vSwitch Linux kernel module only works on
Linux and will provide the highest performance. However, a userspace
datapath is available that should be very portable.
Q: What's involved with porting Open vSwitch to a new platform or switching ASIC?
A: The PORTING document describes how one would go about
porting Open vSwitch to a new operating system or hardware platform.
Comparison of virtualzation platforms: https://en.wikipedia.org/wiki/Comparison_of_platform_virtualization_software
Regarding your last question: You need an underlying OS (e.g. Linux)
Another easy way to experiment with sdn , openvswitch and open flow is mininet.
They have a vm you can download and use with virtualbox, vmware etc
http://mininet.org/
http://mininet.org/download