We Keep Coding

Is there a way to get the name of a running database?

I'm working on Java with an application that persists in Oracle and PostgreSQL (not at the same time). I'd like to get the type of the database that is currently running because I need to work in a different way depending on whether it's oracle or it's Postgresql.

JDBC API should help: getDatabaseProductName(). There are other methods as well that allow to get the product version and the driver name and its version.

What’s the use of "System version" in eclipse "Driver Definitions"?

Eclipse Data Tools Platform has a “Driver Definitions” entry, where you can indicate the JDBC drivers you want to use. When adding one, the wizard asks you to select a “driver template” from a provided list. In my eclipse Neon Java EE version, the list contains, among others, [Name=Other Driver; System Vendor=Derby; System Version=10.2], and [Name=Other Driver; System Vendor=Derby; System Version=10.1]. I can’t see a difference between these two templates, except that they end up with different indicated System Version as a result of the wizard (expectedly). However, in both cases (selecting the 10.2 line or the 10.1 line), when the wizard asks for a jar containing the driver, I use a jar containing the 10.10 version, so this indicated System Version is incorrect in both cases.
My questions are: how does eclipse use these version numbers? If it does not use them, why does eclipse bother displaying a list with different entries for different versions? Can I get problems if the version of the driver I use does not match the indicated one? Should I somehow tell eclipse the right version I use?

The system version is the supported (minimum) version of the target database. The definition of a higher version can contain new features, keywords, data types etc of that database version. In other words: improved/closer support for the database version you are targeting.
For example on of the differences between the Derby 10.1 definition and Derby 10.2 definition is the default length reported for blobs:
In 10.1:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="1024" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
In 10.2:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="2147483647" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
Sometimes there might be no difference at all, but a separate (identical) definition might be provided just to avoid confusion for users to indicate that version is supported, and to make it easier to add corrections/improvements at a later time for that specific database version if necessary.
In short: use the version that is closest (but lower than or equal to) the version you are targetting; in this case: use the 10.2 definition.

What is the neo4j-rest-graphdb version which supports neo4j-community-2.3.0-M02

What is the neo4j-rest-graphdb version which supports neo4j-community-2.3.0-M02 version?
I'm already checked 2.0.0-M06,2.0.0 and 2.0.1 versions but all gives following exception.
java.lang.RuntimeException: Error reading as JSON ''
at org.neo4j.rest.graphdb.util.JsonHelper.readJson(JsonHelper.java:57)
at org.neo4j.rest.graphdb.util.JsonHelper.jsonToSingleValue(JsonHelper.java:62)
at org.neo4j.rest.graphdb.RequestResult.toEntity(RequestResult.java:114)
at org.neo4j.rest.graphdb.RequestResult.toMap(RequestResult.java:120)
at org.neo4j.rest.graphdb.batch.CypherResult.<init>(CypherResult.java:43)
at org.neo4j.rest.graphdb.ExecutingRestAPI.query(ExecutingRestAPI.java:554)
at org.neo4j.rest.graphdb.ExecutingRestAPI.query(ExecutingRestAPI.java:574)
at org.neo4j.rest.graphdb.RestAPIFacade.query(RestAPIFacade.java:235)
at org.neo4j.rest.graphdb.query.RestCypherQueryEngine.query(RestCypherQueryEngine.java:50)
I have no control on db versions so I can't upgrade or downgrade neo4j db version. I'm already spent 2-3 days on this problem so anyone knows a solution for this please help me.

Quoting #MichaelHunger (Best solution for multiple queries in a limited time):
I would not recommend RestGraphDatabase and friends, because it is
slow and outdated.
I think there's no good neo4j-rest-graphdb version for Neo4j 2.3 since it's no longer maintained so you may have to switch to another connector (jdbc-neo4j is maintained)

I suggest you to remove authentication in the new version of Neo4J.
Follow these steps :
Go to options
-> click Edit button in Server Configuration
-> set dbms.security.auth_enabled=false (do not comment on this, because default values still true)

ERROR: operator does not exist: integer = character varying, using Postgres 8.2

I have a Java EE web application developed in an old version of Eclipse (Ganymede if I remember correctly). I recently migrated to Kubuntu 12.04 LTS and migrated the application to Eclipse Kepler (which I downloaded and installed from the Eclipse website). It is using Java Compliance Level 1.6 and the target container is Tomcat 6.
My problem is that I now receive the error:
org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = character varying
when the application encounters a page with a certain Postgres query in it. I'm using the JSTL sql:query and sql:param tags to implement a prepared statement within the jsp page. I know this is considered bad practice, but I'm not the original author and this technique is used throughout the application.
The error occurs because of trying to assign a string to an integer in the sql:param tag. In the previous setup any casting happened transparently and there was no error. With the new setup I receive the error.
I read that more strict type casting was introduced with Postgres 8.3 which would cause this error, but I am using the Postgres 8.2 JDBC 4 jar file within my application so it should work. I am stumped. Perhaps someone has an idea?
I came across a workaround, to multiply the string by 1 before making the comparison:
http://dev-answers.blogspot.co.uk/2010/08/type-coercion-in-jstl-for-sqlparam.html
But this is a bit of a kludge and I would have many pages to modify. But it is academic because I should not be experiencing the problem anyway.
Thanks for reading. Any help greatly appreciated.

You might be using the PostgreSQL 8.2 JDBC driver, but it looks like you're using a newer PostgreSQL server version. Try:
SELECT version()
Betcha it's 8.3 or newer.
These queries aren't really right and should preferably just be fixed. If you must you can alter the system catalogs to allow the cast implicitly, but this should be a temporary workaround only, until you can fix the queries the application is sending. The workaround proposed in that blog post is horrible, but so is JSTL if it doesn't offer type casts in a heavily typed language. Personally I'd be more inclined to force an explicit coercion in the query, eg in the blog's example:
<sql:query var="examples" dataSource="${exampleDataSource}">
select ExampleName as "name"
from ExampleTable
where ExampleId = ?::integer
order by ExampleName ASC
<sql:param value="${param['ID']}"/>
</sql:query>
? :: integer is a type cast in the PostgreSQL shorthand syntax. You can write the SQL standard CAST(? AS integer) if you prefer.
See:
The PostgreSQL 8.3 release notes
Peter's blog post
The lesson here: Always read the release notes of major version upgrades before you upgrade.
Heading

Hibernate Pojo Generator for IBM DB2

I used Hibernate Pojo Generator to generate hibernate stuff. I done it successfully with MySql, but when I tried to generate classes with DB2 it fails. I check hbnpojogen-core-1.4.4-jar-with-dependencies.jar it did not contain DB2 drivers. I added them but it again fails.
I want to know whether Hibernate Pojo Generator works with DB2?

From this tool's website, in the Known Issues section
Although JDBC is meant to hide database differences, each connector driver has its quirks; therefore at the moment, the generator is only known to work correctly on MySQL databases though it has been reported that MS-SQL support looks pretty good too. Support for other databases, notably PostgreSQL, is coming soon. Other databases are as yet untested (submit reports!)
So it seems that it may not work with DB2.

Doing a quick test using:
java -cp db2jcc.jar:db2jcc_license_cu.jar -jar hbnpojogen-core-1.4.4-jar-with-dependencies.jar config.xml
... just produced a ClassNotFoundException. However, using:
java -cp hbnpojogen-core-1.4.4-jar-with-dependencies.jar:db2jcc.jar:db2jcc_license_cu.jar com.felees.hbnpojogen.HbnPojoGen config.xml
... produced the following:
Reading from config: config.xml
Stage 1: Copying skeletons
Stage 2: Getting commit order in 'PARTIAL' strategy
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
With a little more effort, you may be able to get it working.