After I installed DB2 9.7 Express, I tried to enabled DB2 to support PL/SQL by following command:
DB2SET DB2_COMPATIBILITY_VECTOR=ORA
then I got result as below:
DBI1301E Invalid value.
Explanation:
The value specified for the registry variable is invalid.
User response:
Refer to the DB2 Information Center to determine the valid values for
the registry variable.
For sure, I execute db2set command for list all DB2 register:
C:\Documents and Settings\Administrator>db2set -lr | find "COMP"
DB2_PMAP_COMPATIBILITY
Why my database don't known DB2_COMPATIBILITY register ?
PS. this is my DB2 version
DB21085I Instance "DB2" uses "32" bits and DB2 code release "SQL09070" with
level identifier "08010107".
Informational tokens are "DB2 v9.7.0.441", "s090521", "NT3297", and Fix Pack
"0".
Product is installed at "C:\PROGRA~1\IBM\SQLLIB" with DB2 Copy Name "DB2COPY1".
From the documentation, this feature is not enabled for Express, Express-C, or Personal editions.
DB2 9.7 Infocenter - Restrictions on PL/SQL support
I have DB2 9.7 Express-C (Linux AMD64) installed (same build - s090521) and get the same output as you when I try to set the registry variable (as expected).
Related
I'm attempting to configure failed login attempts with MariaDB 10.3. Using the following query (from mysql docs, hoping mariadb would be very similar):
ALTER USER 'mariadb_user'#'localhost' FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME UNBOUNDED;
This returns:
You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use
near 'FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME UNBOUNDED' at line 2
Does MariaDB actually support FAILED_LOGIN_ATTEMPTS? I didn't find anything useful when searching the documentation for relevant keywords.
This feature isn't supported by MariaDB.
As an alternative, you can use the global system variable max_password_errors which was introduced in MariaDB 10.4.
Note: max_password_errors will be ignored for localhost connections (:1, 127.0.0.1)
I had to redo my server (Debian 9) in Proxmox. I updated a package (libc6) and I broke the dependencies (I didn't snapshot it...). One of the affected daemons was MySQL / MariaDB, I could not make a backup from PhpMyAdmin because the daemon does not work and I could not connect to the database.
Now I have installed Debian 10, but I am having problems recovering the database from the other machine.
mysqldump: Couldn't execute 'show create table `xxx.yyy`': Table 'yyy' doesn't exist in engine (1932)
The following errors are prompted when I tried the following solutions:
root#debian:~# mysqldump -u root -p --all-databases > all_databases.sql
Enter password:
mysqldump: Got error: 1932: "Table 'mysql.gtid_slave_pos' doesn't exist in engine" when using LOCK TABLES
root#debian:~# mysqldump --skip-lock-tables -u root -p --all-databases > all_databases.sql
Enter password:
mysqldump: Couldn't execute 'show create table `gtid_slave_pos`': Table 'mysql.gtid_slave_pos' doesn't exist in engine (1932)
Source: https://support.plesk.com/hc/en-us/articles/213931725-Dump-of-the-MySQL-database-hosted-on-the-Plesk-server-fails-mysqldump-table-doesn-t-exist-when-using-LOCK-TABLES
root#debian:~# mysqlfrm --server=xxx:yyy#localhost:3306 test.frm --port=3310
WARNING: Using a password on the command line interface can be insecure.
# Source on localhost: ...
Usage: mysqlfrm --server=[user[:<pass>]#host[:<port>][:<socket>]|<login-path>[:<port>][:<socket>]] [path\tbl1.frm|db:tbl.frm]
mysqlfrm: error: Can't connect to MySQL server on 'localhost:3306' (111 Connection refused)
Source: https://dba.stackexchange.com/a/127813
MariaDB [(none)]> ALTER TABLE mysql.gtid_slave_pos DISCARD TABLESPACE;
ERROR 1932 (42S02): Table 'mysql.gtid_slave_pos' doesn't exist in engine
Source: Restore MySQL database using only .frm and .ibd files
Is there any option left?
EDIT:
I'll answer some questions danblack asked me.
How did I get into this state?
I don't exactly know it but I think that I broke MySQL after I tried to restart several times mysqld/mariadb service while I tried several solutions downgrading libc6 or trying to make mariadb to run again.
What was the MySQL/MariaDB version in Debian 9?
mariadb Ver 15.1 Distrib 10.1.44-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
What is the version in Debian 10?
mariadb Ver 15.1 Distrib 10.3.22-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
Did I copy the entire datadir from one to another?
No, I didn't try that... But I didn't find anything useful on stackoverflow sites nor google.
Did I run mysql_upgrade?
No, I didn't try that maybe by updating mariadb in Debian 9 could be a possible solution. But reviewing packages for Debian 9, I didn't found the mariadb 10.3 version for Debian 9 (the one that clib6 2.30-10 requires, I was on 2.14).
Can you take a mysqldump of other databases in the server (ie. not the mysql named one)?
Yes, I did backups for some databases but I couldn't backup all of them (only 3 or 4 from 10).
You have at least 2 options:
Option #1: Fix it in-place.
Create a snapshot and/or backup of the server before trying to fix anything.
Remove mariadb.
Install mariadb...which should fix any software issues preventing it from starting up.
Once it is working, create a backup of your databases using mysqldump.
Option #2: Create a new server.
Spin up another virtual machine just like it (install the same OS and MariaDB version).
Stop the new mariadb service and copy the database files from the old server to the new. The default location on Ubuntu is /var/lib/mysql/
Once you overwrite the files, start the mariadb service and jump into the mysql prompt to verify that the databases show up. (e.g. show databases;)
Once it is working, create a backup of your databases using mysqldump.
This is how I install MariaDB onto a server and setup automated backups: https://hammondslegacy.com/forum/viewtopic.php?f=40&t=266
The syntax is
`dbname`.`tablename`
not
`dbname.tablename`
Unfortunately, I will not be able to create a good repro for this issue without sharing confidential creds to the database I am having issues with. Hopefully I have enough information below to flag any obvious problems that ODBC experts will understand.
Background
I am running a MacBook Pro with the following specs:
Model Name: MacBook Pro
Model Identifier: MacBookPro15,1
Processor Name: 6-Core Intel Core i7
Processor Speed: 2.6 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 9 MB
Hyper-Threading Technology: Enabled
Memory: 32 GB
Boot ROM Version: 1037.0.78.0.0 (iBridge: 17.16.10572.0.0,0)
My ODBC connection is set using FreeTDS as specified here.
The relevant portion of freetds.conf is as follows:
# The POC SQL Server
[POC]
host = 172.22.238.154
port = 1433
tds version = 7.3
My odbcinst.ini file is as follows:
[FreeTDS]
Description=FreeTDS Driver for Linux & SQL Server
Driver=/usr/local/lib/libtdsodbc.so
Setup=/usr/local/lib/libtdsodbc.so
UsageCount=1
My odbc.ini file is specified as follows:
[POC]
Description = Connecton to Partners for our children SQL Server
Driver = FreeTDS
Servername = POC
I am trying to make a connection to a SQL Server 2012 database (via VPN) using the following connection information in R:
con <- DBI::dbConnect(odbc::odbc()
,dsn = "POC"
,uid = Sys.getenv("MSSQL_UN")
,database = "CA_ODS"
,pwd = Sys.getenv("MSSQL_PW"))
This generates the following connection object:
> con
<OdbcConnection> POC2
Database: CA_ODS
Microsoft SQL Server Version: 11.00.7001
In general, this connection works as expected. I can query the database using DBI::dbGetQuery(con, "select * from MyTable"), dplyr::tbl(con, MyTable), etc. without issue.
Problem
RStudio, however, is only displaying every other letter of the database objects, and truncating the object names after the first several letters. The following screenshot should illustrate the issue well:
The database I am trying to connect to is called CA_ODS. However, the RStudio object browser is only displaying every other letter of the database name (i.e. the DB is listed as C_D).
This does not appear to be limited to RStudio per se either. While the results of the actual database queries work fine as described above, the returned names from the INFORMATION_SCHEMA appear to match the information in the object browser. Below, when run directly from SQL Server Management Studio, the returned TABLE_CATALOG is CA_ODS, TABLE_SCHEMA is ndacan, etc. When run via the DB connection, however, I get the following.
> DBI::dbGetQuery(con, "SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_SCHEMA='ndacan'")
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE
1 C_D naa f21v BASE TABLE
Question
Any suggestions as to how I can respecify my ODBC connection in R or in my FreeTDS configs to get the full name of database objects returned?
As noted in #r2evans comments, this appears to be an issue with odbc, running in R 3.6.0, on a Mac.
In general, it appears that this can be fixed by reinstalling odbc from source install.packages("odbc", type = 'source').
As also noted in the comments, I had recently upgraded my Mac to Catalina. Prior to installing odbc from source I needed to first reinstall XCode using xcode-select --install from my terminal.
As can be seen in the screen capture below, I am now getting the full object names displayed from the odbc connection.
After I upgraded my MySQL version from 5.6 to 5.7, the AzerothCore installer fails with errors like:
ERROR 1067 (42000) at line 234: Invalid default value for 'last_login'
ERROR 1292 (22007) at line 266: Incorrect datetime value: '0000-00-00 00:00:00' for column 'last_login' at row 1
and:
Can't find any matching row in the user table
In fact, you better do it like this (to avoid removing default modes):
-- Select the sql modes
SELECT ##sql_mode;
-- Remove the 2 modes NO_ZERO_IN_DATE and NO_ZERO_DATE and run this query
SET sql_mode = 'mode_1,mode_2,mode_3,mode_4,mode_5';
Also this can be put directly in mysql configuration.
After [mysqld]:
[mysqld]
sql_mode = mode_1,mode_2,mode_3,mode_4,mode_5
Note: ONLY_FULL_GROUP_BY can be kept
EDIT: As of march 2019, it's probably not needed at all, we have fixed this but it might occur again in the future
EDIT: this answer is a bit outdated, some of the issues with MySQL 5.7 have been resolved in the latest version
As stated in the requirements page of the AC wiki:
AzerothCore does not officially support MySQL version >= 5.7, but there is a way to get it up and running.
You have to remove ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE and NO_ZERO_DATE flags from MySQL's sql_mode variable in the MySQL config file so that all queries updates and core statements can be applied correctly.
I've found it useful to set my SQL mode to the empty string (which in my case solved all the issues with MySQL 5.7):
SET GLOBAL sql_mode = ''
you can run that sql statement via terminal using:
mysql -e "SET GLOBAL sql_mode = '';"
or alternatively you can manually set the SQL mode before running any SQL statements:
SET sql_mode = '';
I'm trying to config a connection with SQLBase with odbc driver on Windows and I never did that, but I'm getting the error:
Connection failed with SQL State: "HY092"
I'm using the Windows ODBC Administrator to try add the connection. In the field "Config Filename (INI)" of the configuration screen I put: "C:\Program Files (x86)\Centura\sql.ini" and I add "C:\Program Files (x86)\Centura\" to the PATH system variable.
In the application (.NET) I'm getting the message:
ERROR [HY092] [Gupta][ODBC Driver]Invalid attribute/option identifier
My sql.ini file has the content:
[win32client]
clientname=CWBXXX
[win32client.dll]
comdll=sqlws32
[win32client.
serverpath=server3,<SERVER_IP>,2155/<BASE_NAME>
Anyone could help me? Thank you.
Good to see you are using SQLBase . Awesome.
Two important settings to get right.
1) Make sure you are using the correct ODBC administrator
I'm guessing 32 bit in %systemdrive%\Windows\SysWoW64\odbcad32.exe.
If not , use the 64bit one in %systemdrive%\Windows\System32\odbcad32.exe.
Under System DSN tab Add the correct driver for the database. Either 'Centura SQLBase 3.6 32bit Driver' or the 'Gupta SQLBase 12.x' driver if you are running SQLBase 12.
Under the Configure Tab, specify the Data Source Name that you will use in your sql.ini. THEY MUST MATCH.
2)a. Make sure you only ever have 1 sql.ini on the client. Ever.
2)b. sql.ini needs the ODBC driver specified in the client section:
[win32client.dll]
comdll=sqlodb32
[odbcrtr]
odbctrace=off
longbuffer=32767
buffrow=10000
remotedbname=[dB Name specified in ODBC] ,
DSN=[Data Source Name specified in ODBC]
(without the square brackets eg. remotedbname=MyDatabase,DSN=MyDatasetName whatever names you have specified in ODBC admin.)