DBVisualizer displays null on date field holding '0001-01-01' - dbvisualizer

I issued an SQL statement in DbVis:
select vestdate, name from person where vestdate is not null
And got many results where DbVisualizer showed vestdate as (null)!
After investigating, I discovered that the vestdate was '0001-01-01', so the query correctly returned these records, but DbVisualizer displays them as (null).
I have just switched from windows 8 to windows 10.
It works on windows 8 (displays '0001-01-01'), but not not windows 10 (displays null):
Product: DbVisualizer Pro 11.0.4 [Build #3103]
OS: Windows 8.1
OS Version: 6.3
OS Arch: amd64
Java Version: 1.8.0_252
Java VM: OpenJDK 64-Bit Server VM
Java Vendor: AdoptOpenJDK
Java Home: c:\program files\dbvisualizer\jre
DbVis Home: C:\Program Files\DbVisualizer
User Home: -------
PrefsDir: -------
SessionId: 55
BindDir: -------
Product: DbVisualizer Pro 11.0.5 [Build #3113]
OS: Windows 10
OS Version: 10.0
OS Arch: amd64
Java Version: 1.8.0_252
Java VM: OpenJDK 64-Bit Server VM
Java Vendor: AdoptOpenJDK
Java Home: c:\program files\dbvisualizer\jre
DbVis Home: C:\Program Files\DbVisualizer
User Home: -------
PrefsDir: -------
SessionId: 968
BindDir: -------
Any ideas how to make the program show me the real value, not the interpreted value of null?

The issue is explained in an IBM support document:
Problem
Trying to insert a date value into a date column before 1940 or after 2039 will represent the date as NULL within the respective database table.
Cause
This is caused by a limitation with the IBM i database Toolbox JDBC driver as detailed in the related link:
How does the Toolbox JDBC driver deal with dates before 1940 (or after 2039)?
The IBM i database supports several date formats. The Toolbox JDBC driver uses the date format that is set up as the default on the IBM i system. This default is usually set to "mdy" which only supports dates between 1940 and 2039. You can override the date format by specifying the "date format" property when opening the JDBC connection. The best choice is "iso", which supports a full four-digit date. The easiest way to do this is to add ";date format=iso" to the end of the URL used when connecting to the database.
Resolving The Problem
Appending the ";date format=iso" to the host connection property for the applicable database
via Preferences-> EGL-> SQL Database Connections will then show the respective dates correctly eg:
1939-01-01.
The issue can be fixed in DBVisualizer by doing the following:
Database -> Edit Database Connection(s)...
Select Properties tab
Select Driver Properties
Edit parameters date format and time format to be iso
Apply Changes
Disconnect and reconnect

Related

LUW DB2 JDBC Connection Issue on Open JDK 11

I am not able to connect LUW DB2 database using JDBC Type4 driver on Open Zulu JDK 11.
I have tried all available latest DB2 JDBC Drivers (Type 4) but same issue with all drivers on JDK 11. Things are working fine on JDK 8.
Getting below error
Exception in thread "main" java.lang.NumberFormatException: For input string: "B"
at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Integer.parseInt(Integer.java:652)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at com.ibm.db2.jcc.c.xc.<init>(xc.java:64)
at com.ibm.db2.jcc.b.f.<init>(f.java:44)
at com.ibm.db2.jcc.b.b.cb(b.java:1945)
at com.ibm.db2.jcc.c.p.a(p.java:3284)
at com.ibm.db2.jcc.b.b.a(b.java:625)
at com.ibm.db2.jcc.b.b.<init>(b.java:334)
at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:165)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:677)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
at com.aonhewitt.Test.main(Test.java:14)
Test Java Code
Class.forName("com.ibm.db2.jcc.DB2Driver");
Connection conn = DriverManager.getConnection("jdbc:db2://hostname:port/database","userid","password");
I would appreciate if anyone can help me here to connect to a DB2-LUW database from JDK 11
C:\>java -cp db2jcc4.jar com.ibm.db2.jcc.DB2Jcc -version
IBM Data Server Driver for JDBC and SQLJ 4.25.23
C:\>java -cp jcc-11.5.4.0.jar com.ibm.db2.jcc.DB2Jcc -version
IBM Data Server Driver for JDBC and SQLJ 4.27.25

MySQL-Workbench Connection Fail

Try to ask a question because the DB connection in MySQL Workbench continues to fail.
Enter connection information and Test Connection was successful.
However if i select the appropriate DB Connection in workbench home, the connection success window does not appear.
local DB : mysql Ver 15.1 Distrib 10.3.14-MariaDB, for Win64 (AMD64), source revision ab7b9cf9122f6eb02744082db8672a920ae6009f
Server DB : mysql Ver 15.1 Distrib 10.3.14-MariaDB, for Win64 (AMD64), source revision ab7b9cf9122f6eb02744082db8672a920ae6009f
MySQL Workbench Version : mysql-workbench-community-8.0.16-winx64
The same error occurs even if the version of Workbench is changed to 19 or 20.
How to solve it?
Manage Server Connections - screenshot
MySQL Workbench - screenshot
------More details---------
If you check the log file in the top Help tab of Workbench, you can see the log as below.
11:23:15 [INF][SQL Editor Form]: Opened connection 'DB Name' to mariadb.org binary distribution version 10.3.14-MariaDB
11:23:15 [ERR][ WBContext]: Unsupported server version: mariadb.org binary distribution 10.3.14-MariaDB
However, the connection is normally established on the other coworker's PC.

Why is my Hive QL Query that I run in SSMS via Openquery through the Hortonworks ODBC Driver producing an error?

I set up a connection to a Hive server using the Hortonworks ODBC Driver for Apache Hive. Version info is below:
OS: Windows Server 2012 R2 Standard
Hive: 1.2.1000.2.6.5.4-1
Hadoop: 2.7.3.2.6.5.4-1
Hortonworks ODBC Driver for Apache Hive
ODBC Version: 03.80
Driver Version: 2.1.12.1017
Bitness: 64-bit
Locale: en_US
I can run the queries below using the connector that I configured in Teradata SQL Assistant with no issues. I set up my DSN as a linked server in SSMS. However, when I attempt to run the queries in SSMS using openquery, I have some issues. Info on my SQL Server is below:
Microsoft SQL Server 2016 (SP2-CU3) (KB4458871) - 13.0.5216.0 (X64) Sep 13 2018 22:16:01 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) (Hypervisor)
Here is some info on the table that I am querying:
Table Name: instrumentapps_event
Using OPENQUERY, I am capable of querying the Hive DB through SSMS with the following query:
SELECT * FROM OPENQUERY(KMhivehttp, 'select * from dmfwk_gold.instrumentapps_event')
The above query returns the contents of the desired table. However, the query below produces an error:
SELECT * FROM OPENQUERY(KMhivehttp, 'select * from dmfwk_gold.instrumentapps_event WHERE to_date(from_unixtime(UNIX_TIMESTAMP(load_ts,''yyyy/MM/dd''))) >= to_date(''2019-03-01'')')
The error is as follows:
Msg 7355, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "KMhivehttp" supplied inconsistent metadata for a column. The name was changed at execution time.
How can I fix this?
While I'm unsure how to fix the problem that I previously faced (I suspect it to be a bug with the Hortonworks ODBC driver), I did discover a workaround.
Instead of running:
SELECT * FROM OPENQUERY(KMhivehttp,
'SELECT *
FROM dmfwk_gold.instrumentapps_event
WHERE to_date(from_unixtime(UNIX_TIMESTAMP(load_ts,''yyyy/MM/dd''))) >=
to_date(''2019-03-01'')
')
I now use:
SELECT * FROM OPENQUERY(KMhivehttp, 'select * from dmfwk_gold.instrumentapps_event')
WHERE load_ts >= CAST('2019-03-01' AS DATE);
This allows me to avoid any metadata errors.

Liquibase - DB2 AS/400 - generateChangeLog throwing Exception "SYSCAT type *FILE not found"

I am trying to generate a Liquibase change log by running the command generateChangeLog, but I get the following error:
Starting Liquibase at Fri, 20 Apr 2018 14:26:14 GMT (version 3.6.1
built at 2018-04-11 08:41:04)
Unexpected error running Liquibase:
liquibase.exception.DatabaseException:
com.ibm.as400.access.AS400JDBCSQLSyntaxErrorException: [SQL0204]
REFERENCES in SYSCAT type *FILE not found.
liquibase.exception.LiquibaseException:
liquibase.command.CommandExecutionException:
liquibase.exception.DatabaseException:
liquibase.exception.DatabaseException:
com.ibm.as400.access.AS400JDBCSQLSyntaxErrorException: [SQL0204]
REFERENCES in SYSCAT type *FILE not found.
at
liquibase.integration.commandline.CommandLineUtils.doGenerateChangeLog
(CommandLineUtils.java:279)
at liquibase.integration.commandline.Main.doMigration(Main.java:1043)
at liquibase.integration.commandline.Main.run(Main.java:191)
at liquibase.integration.commandline.Main.main(Main.java:129)
My environment is:
DB2 UDB for AS/400 version 07.01.0000 V7R1m0
AS/400 Toolbox for Java JDBC Driver 10.2
liquibase 3.6.1
Java 8
Maven 3.3.3
syscat.references is not available on Db2 for i. Actually Db2 for i doesn't have a schema named SYSCAT at all.
qsys2.syscstdep seems to be the closest match...
INFORMATION_SCHEMA is the ANSI & ISO standard name for the DB catalog schema. On Db2 for i, it is an alias for QSYS2.
Edit
From the comment by #jmarkmurphy on the OP, it appears there's an Db2 for i Liquibase extension. I don't know for sure, but I'd suspect that installing that would redirect the query to the correct Db2 for i schema & table.

How to easily determine version of .fdb-file (Firebird database)

When looking at a .fdb-database of a proprietary software (probably using Firebird Embedded), how can I determine which version of Firebird I need to setup?
The only way I can currently imagine is by having a look with a hex viewer at 'ODS-version' which is part of a page header, which is most likely also used as format for the file header, and then somehow by digging through respository history find out which Firebird release supports which ODS-Version. ODS-version, atleast nowadays, is encoded like stated below.
Related docs: https://firebirdsql.org/file/documentation/reference_manuals/reference_material/Firebird-Internals.pdf
Related code:
https://github.com/FirebirdSQL/firebird/blob/3dd6a2f5366e0ae3d0e6793ef3da02f0fd05823a/src/jrd/ods.h
and
inline USHORT DECODE_ODS_MAJOR(USHORT ods_version)
{
return ((ods_version & 0x7FF0) >> 4);
}
inline USHORT DECODE_ODS_MINOR(USHORT ods_version)
{
return (ods_version & 0x000F);
}
Is there really no easier way to determine required firebird version, e.g. with some cli-tool?
If you have a Firebird installation at hand, you can use gstat to check the ODS for a database. For example:
gstat -h <path-to-your-database>
If the ODS version of the database is supported by the version of gstat, you'll get something like:
Database "D:\DATA\DB\FB4\FB4TESTDATABASE.FDB"
Gstat execution time Sat Mar 17 18:08:09 2018
Database header page information:
Flags 0
Generation 308
System Change Number 0
Page size 16384
ODS version 13.0
Oldest transaction 393
Oldest active 394
Oldest snapshot 394
Next transaction 395
Sequence number 0
Next attachment ID 150
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 6, 2017 14:05:48
Attributes force write
Variable header data:
*END*
Here ODS version 13.0 means it is a Firebird 4 database.
If the gstat version does not support the ODS version of the database, you will get an error like (eg in this case using a Firebird 4 gstat on a Firebird 2.5/ODS 11.2 database):
Wrong ODS version, expected 13, encountered 11
This has its downsides though: it doesn't provide the ODS minor versions, and for example when using a Firebird 2.0 (ODS 11.0) or 2.1 (ODS 11.1) gstat to access a Firebird 2.5 (ODS 11.2) database, this will lead to the unhelpful error message:
Wrong ODS version, expected 11, encountered 11
The quickest route is to use a Firebird 2.5 gstat as this will allow you to pinpoint the exact ODS versions between 10 (Firebird 1) and 11.2 (Firebird 2.5), and at the same time the error message will allow you to pinpoint if you need a newer version (eg ODS 12 is Firebird 3, ODS 13 is Firebird 4).
However, you will also need to look at the Implementation output of gstat. Firebird database files have platform specific storage (although this has been reduced since Firebird 2.0). For example in Firebird 1.5 and earlier (ODS 10), a database from a 32 bit Firebird cannot be accessed by a 64 bit Firebird. A Firebird database from a little endian platform (most common) cannot be read on a big endian platform (and vice versa).
Within these limitations, a Firebird 2.5 installation can read databases with ODS 10 through 11.2. Firebird 3 can only read ODS 12, and Firebird 4 only ODS 13.
If there are platform mismatches (eg old 32/64 bit or little/big endian) or unsupported ODS versions, you will need to have a transportable backup (gbak) to convert and/or upgrade.
For an overview of ODS versions and accompanying Firebird (or InterBase) version, see All Firebird and InterBase On-Disk-Structure (ODS) versions.