Trying to follow the directions for installing the MySQL ODBC driver.
When I try to run:
myodbc-installer -a -d -n "MySQL ODBC 8.0 Driver" -t "Driver=/usr/local/lib/libmyodbc8w.so"
It says:
[ERROR] SQLInstaller error 6: Unable to find component name
I've found a handful of cases of people reporting this same message, e.g., here and here. Yet there seems to be no resolution.
Noticing the slight variations in the -n name string for the various drivers, I wondered if perhaps the name was something subtly different and the documentation hadn't been updated. But I used a hex editor to look in /usr/local/lib/libmyodbc8w.so and the literal string "MySQL ODBC 8.0 Driver" is in it.
There may be some instances of a name mismatch causing the problem (e.g. in one of the linked-to cases, they use -n "MySQL" instead of the prescribed -n "MySQL ODBC 5.3" from the notes).
However...in my case it was a matter of not using sudo. The error message is not very helpful in indicating that the problem could be a matter of privileges! :-/ But at the very top of the linked instruction page it says (emphasis mine):
To install the driver from a tarball distribution (.tar.gz file), download the latest version of the driver for your operating system and follow these steps, substituting the appropriate file and directory names based on the package you download (some of the steps below might require superuser privileges)
What's going on is that unixodbc has system-wide odbcinst.ini and odbc.ini. It is stated that you should not be editing these files directly, but they are edited via an API that unixodbc provides. That API is called by the MySQL helper utility called myodbc-installer:
The error message is delivered by this print_installer_error() routine
...which is called from add_driver() when the routine SQLInstallDriverExW() returns false
(Note: unixodbc on most platforms provides the (W)ide Character version of SQLInstallDriverEx(), but myodbc-installer defines its own SQLInstallDriverExW() if it is not available via a shim.)
This API apparently doesn't have a way of saying it can't get the necessary privileges to the files (in /usr/local/etc or perhaps just in /etc). So myodbc-installer is just parroting what it got. Sigh.
Related
I'm trying to follow the diesel.rs tutorial using PostgreSQL. When I get to the Diesel setup step, I get an "authentication method 10 not supported" error. How do I resolve it?
You have to upgrade the PostgreSQL client software (in this case, the libpq used by the Rust driver) to a later version that supports the scram-sha-256 authentication method introduced in PostgreSQL v10.
Downgrading password_encryption in PostgreSQL to md5, changing all the passwords and using the md5 authentication method is a possible, but bad alternative. It is more effort, and you get worse security and old, buggy software.
This isn't a Rust-specific question; the issue applies to any application connecting to a Postgres DB that doesn't support the scram-sha-256 authentication method. In my case it was a problem with the Perl application connecting to Postgres.
These steps are based on a post.
You need to have installed the latest Postgres client.
The client bin directory (SRC) is "C:\Program Files\PostgreSQL\13\bin" in this example. The target (TRG) directory is where my application binary is installed: "C:\Strawberry\c\bin". My application failed during an attempt to connect the Postgres DB with error "... authentication method 10 not supported ...".
set SRC=C:\Program Files\PostgreSQL\13\bin
set TRG=C:\Strawberry\c\bin
dir "%SRC%\libpq.dll" # to see the source DLL
dir "%TRG%\libpq__.dll" # to see the target DLL. Will be replaced from SRC
cp "%SRC%\libpq.dll" %TRG%\.
cd %TRG%
pexports libpq.dll > libpq.def
dlltool --dllname libpq.dll --def libpq.def --output-lib ..\lib\libpq.a
move "%TRG%"\libpq__.dll "%TRG%"\libpq__.dll_BUP # rename ORIGINAL name to BUP
move "%TRG%"\libpq.dll "%TRG%"\libpq__.dll # rename new DLL to ORIGINAL
At this point I was able successfully connect to Postgres from my Perl script.
The initial post shown above also suggested to copy other DLLs from source to the target:
libiconv-2.dll
libcrypto-1_1-x64.dll
libssl-1_1-x64.dll
libintl-8.dll
However, I was able to resolve my issue without copying these libraries.
Downgrading to PostgreSQL 12 helped
I've installed Bareos 20.0.1 on Ubuntu 20.04.3 according to their documentations here.
I'm trying to backup a remote PostgreSQL database and apparently, there are three possible scenarios and the pros of the PostgreSQL Plugin (third solution), makes it the obvious choice.
Following the PostgreSQL Plugin documentations, in the Prerequisites for the PostgreSQL Plugin section, there is a line saying:
The plugin must be installed on the same host where the PostgreSQL database runs.
Now what I'm failing to understand is that, if I'm supposed to install the plugin on my database node, how will the bareos machine and the plugin on the db machine communicate?
Furthermore, I've checked out the source code for this module on their GitHub, and I see that the plugin source code tries to find files locally and that is a proof to the aforementioned statement.
In a desperate act, I tried installing the plugin and its dependencies on the bareos node and I keep getting the error Error: python3-fd-mod: Could not read Label File /var/lib/postgresql/13/main/backup_label which is actually trying to find the backup_label file in the bareos node.
Here is the configuration for my fileset:
FileSet {
Name = "psql"
Include {
Options {
compression=GZIP
signature = MD5
}
Plugin = "python"
":module_path=/usr/lib/bareos/plugins"
":module_name=bareos-fd-postgres"
":postgresDataDir=/var/lib/postgresql/13/main"
":walArchive=/var/lib/postgresql/13/wal_archive/"
":dbHost=DATABASE_DNS"
":dbuser=DATABASE_USER"
}
}
Note that the plugin document specifies the dbHost parameter as:
useful, if socket is not in default location. Specify socket-directory with a leading / here
However, since I'm trying a remote database, I'm using the DNS address of the remote database. I verified the bareos connection to database and made sure the backup_label file gets created while the PostgreSQL backup job runs.
I'll be happy to provide more details if necessary. Appreciate any help or even guesses :-D
I'm attempting to import an SQL dump in PgAdmin 4 using the psql client - However the error message returned is - The system cannnot find the file specified.
Here is a screenshot of my psql client -
The file films.sql is currently stored on my desktop, but I suspect the default location that the psql client accesses is not my desktop? Is there anyway to set the location that the client looks in order to resolve this?
The file SQL is viewable here: https://github.com/datacamp/courses-intro-to-sql/tree/master/datasets
I simply want to get the database on my local machine so that I don't need to store queries in an online learning platform. It would be best if this database is available locally to query and practice on.
I've attempted to execute the whole SQL file as a query on the films database but this does not seem to be working either and returns 'Asynchronous query execution/operation underway.
Query returned successfully in 388 msec.' - However it seems to be the case that the Asynchronous query never completes when I refresh the database.
Please can someone help?
Just give the path to your file:
psql -d my_database -f /path/to/the/file.sql
psql -d my_database -f C:/path/to/the/file.sql
Depending on whether you are on a unix/linux machine or Windows.
Oh, and if you aren't familiar with file paths you may want to take a step back and become more familiar with general computer terminology before diving into a RDBMS. Your learning will be much easier if you have a solid foundation to build upon.
I suspect this question might be moot for the asker at this point, but for anyone else stumbling upon it like I did: the interactive connection info prompts are provided by a batch script (in Windows, I'd guess there's an analogous shell script for Unix) called runpsql.bat, which then just passes your inputs as commandline arguments to the psql.exe executable. I was getting this error because I had migrated my Postgres installation and the batch script was calling a nonexistent path for psql.exe, hence The system cannot find the file specified. I edited runpsql.bat to point to the correct location of psql.exe and that resolved the issue. So for OP, I would look into PgAdmin4 and see where it's (presumably) calling runpsql.bat, then make sure that that calls psql.exe with the correct path.
I'm currently working on a small COBOL project and I'm using OpenCobolIDE.
I also downloaded DB2 Express and I'm able to use it by running the "Commande line processor"
Now my question is the follow one : How can I make a connection between OpenCobolIDE and DB2 ?
I saw that it was possible to use "esqlOC" but I didn't find a lot of documentation and I'm still lost at the moment.
Kind regards
I know that's it's against SO policy, but here is a link; http://db2twilight.blogspot.nl/2014/01/linuxdb2-running-cobol-with-inline-sql.html The code isn't that long, but I found no disclaimer, so assumed copyright goes to the blogger, Dick Reitveld. The post is a tutorial on linking DB2 to GnuCOBOL (was OpenCOBOL), and not how to inform the OpenCOBOLIDE how to do the build, but hopefully this fits in with your question.
The build rules are listed in a shell script on the same page.
Basically it comes down to, creating a COBOL source file with EXEC SQL statements, running them through the DB2 preprocessor, then compiling the generated sources with cobc.
db2 connect to sample
db2 prep program.sqb bindfile target ANSI_COBOL
cobc program.cbl -static -Wall -L/path/to/db2libs/sqllib/lib64 -ldb2 -v -x -save-temps -O
db2 bind program.bnd
db2 connect reset
Where "program" is your filename, with .sqb inputs and will generate .cbl and .bnd, and the
-L/path/to/.../
is the full path to where your DB2 install has placed the DB2 support libraries.
I am trying to install RMySQL on my Windows 7 Professional x64 machine using R-2.15.1, RTools 2.16 (also tried 2.15), and MySQL 5.5.
I have copied libmysql.dll and libmysql.lib into mysql\lib\opt and \bin. I have also copied libmysql.dll into R-2.15.1\bin.
I have set Renviron.site properly as confirmed by Sys.getenv('MYSQL_HOME') using both the 8.3 nomenclature as well as non-8.3 nomenclature.
Sample output for Sys.getenv('MYSQL_HOME') is "C:/Program Files/MySQL/MySQL Server 5.5/" (quotes included). When I use 8.3 nomenclature it also is correct.
Here is the relevant part of my PATH:
c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;C:\Program Files\MySQL\MySQL Server 5.5\lib\opt;c:\program file\R\R-2.15.1\bin;
I have manually inserted it into the registry in the right location (because the MySQL 5.5 doesn't do that properly - it only puts it under the Wow6432Node) AND I inserted it into the system variables to deal with this error:
Error in utils::readRegistry("SOFTWARE\MySQL AB", hive = "HLM", maxdepth = 2) :Registry key 'SOFTWARE\MySQL AB' not found
I even tried
Sys.setenv('MYSQL_HOME=C:/Program Files/MySQL/MySQL Server 5.5/')
However, when I try to install RMySQL I get the following error:
checking for $MYSQL_HOME... not found... searching registry...
cygwin warning:
MS-DOS style path detected: C:/PROGRA~1/R/R-215~1.1/bin/x64/Rscript
Preferred POSIX equivalent is: /cygdrive/c/PROGRA~1/R/R-215~1.1/bin/x64/Rscript
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Try setting MYSQL_HOME to one of the following (you may have to use the non-8dot3 file name):
ERROR: configuration failed for package 'RMySQL'
If I am understanding the error properly, it can't find MYSQL_HOME, even though it calls it properly using Sys.getenv, is located in the proper location in the registry, AND is a system variable.
I have a similar issue with my Windows 7 x64 installation.
I think the problem is not related to the MYSQL_HOME, but to the registry.
As you can see here:
https://dev.mysql.com/doc/refman/5.1/en/windows-install-wizard.html
the default location for the registration is not SOFTWARE\MySQL AB but SOFTWARE\Wow6432Node\MYSQL AB.
I believe the answer is here:
http://martin.von-gagern.net/howtos/20110728-rmysql/