You can translate the question and the replies:

Unable to connect to the database when creating base view on DB2 datasource or reading data after upgarde to v7

Hi I have migated from Denodo Expressv6 to Denodo Express v7 and for one of the DB2 database, I get the error below when adding a base view: *Unable to connect to the database: Internal error: sun.nio.cs.MS1252.getDecoderSingleByteMappings()Ljava/lang/String;* Or when executing on an existing (migrated) base view: *TSTAMVTAGNTSESS [BASE] [ERROR] TSTAMVTAGNTSESS [JDBC WRAPPER] [ERROR] Received exception with message 'sun.nio.cs.MS1252.getDecoderSingleByteMappings()Ljava/lang/String;' TSTAMVTAGNTSESS#0 [JDBC ROUTE] [PROCESSING] * Note that the test connection is retuning with succes and that the DB2 (v9.7) database is on a windows server. Can you help?
user
31-05-2018 15:17:49 -0400

3 Answers

Hi, In my opinion, this looks like a potential JAVA issue. When moving from Denodo Express 6.0 to Express 7.0, the internal JVM on the platform moved from Java 1.7 to Java 1.8 (shown [here](https://community.denodo.com/kb/view/document/Java%20versions%20supported%20by%20the%20Denodo%20Platform?category=Installation+%26+Updates)). I would double check two things first just in case: 1) The installer for Express 7.0 you used is the same architecture as your computer (32 bit vs 64 bit). 2) The java version your computer is pointing to at the time of the platform execution is the java version that comes with the Express Edition (Java 1.8). Alternatively, you can look at the vdp.log file to see more details about the error to pinpoint it. You can find the vdp.log file at: '<DENODO HOME>'/logs/vdp/vdp.log Hope this helps!
Denodo Team
01-06-2018 12:41:35 -0400
Hello, Thanks for your quick reply, I have double check the installer (denodo-express-install-70-win64) and its aligned with my computer architecture: /* From the vdp.log */ *Starting Denodo Platform 7.0 - Operating system: Windows Server 2012 R2 (amd64) - Java(TM) SE Runtime Environment (build 1.8.0162-b12) - Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)* The error : > 12152408 [RMI(1098)-10.219.54.69-58] FATAL 2018-05-31T15:02:24.207 com.denodo.vdb.interpreter.execution.Action [] - Action.run: Application ERROR: Unexpected ERROR: sun.nio.cs.MS1252.getDecoderSingleByteMappings()Ljava/lang/String; > java.lang.NoSuchMethodError: sun.nio.cs.MS1252.getDecoderSingleByteMappings()Ljava/lang/String; > at sun.io.ByteToCharCp1252.<init>(ByteToCharCp1252.java:45) ~[rt17.jar:1.8.0_162] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_162] > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_162] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_162] > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_162] > at java.lang.Class.newInstance(Class.java:442) ~[?:1.8.0_162] > at sun.io.Converters.newConverter(Converters.java:249) ~[rt17.jar:1.8.0_162] > at sun.io.Converters.newConverter(Converters.java:274) ~[rt17.jar:1.8.0_162] > at sun.io.ByteToCharConverter.getConverter(ByteToCharConverter.java:86) ~[rt17.jar:1.8.0_162] > at com.ibm.db2.jcc.am.r.<init>(r.java:10) ~[?:?] > at com.ibm.db2.jcc.am.p.a(p.java:10) ~[?:?] > at com.ibm.db2.jcc.am.Agent.getByteToCharConverter(Agent.java:463) ~[?:?] > at com.ibm.db2.jcc.t4.cc.a(cc.java:2374) ~[?:?] > at com.ibm.db2.jcc.t4.bb.a(bb.java:3441) ~[?:?] > at com.ibm.db2.jcc.t4.bb.a(bb.java:1911) ~[?:?] > at com.ibm.db2.jcc.t4.bb.b(bb.java:1842) ~[?:?] > at com.ibm.db2.jcc.t4.bb.a(bb.java:1808) ~[?:?] > at com.ibm.db2.jcc.t4.bb.m(bb.java:597) ~[?:?] > at com.ibm.db2.jcc.t4.bb.l(bb.java:355) ~[?:?] > at com.ibm.db2.jcc.t4.bb.f(bb.java:98) ~[?:?] > at com.ibm.db2.jcc.t4.q.e(q.java:81) ~[?:?] > at com.ibm.db2.jcc.t4.rb.k(rb.java:160) ~[?:?] > at com.ibm.db2.jcc.am.oo.lb(oo.java:2330) ~[?:?] > at com.ibm.db2.jcc.am.po.b(po.java:4505) ~[?:?] > at com.ibm.db2.jcc.am.CallableStatement.ic(CallableStatement.java:156) ~[?:?] > at com.ibm.db2.jcc.am.DatabaseMetaData.executeCatalogQuery(DatabaseMetaData.java:7836) ~[?:?] > at com.ibm.db2.jcc.am.DatabaseMetaData.getSchemasX(DatabaseMetaData.java:6420) ~[?:?] > at com.ibm.db2.jcc.am.DatabaseMetaData.getSchemas(DatabaseMetaData.java:6348) ~[?:?] > at com.denodo.util.jdbc.DatabaseInspector.getCatalogAndSchemaNames(DatabaseInspector.java:402) ~[denodo-commons-jdbc-util.jar:7.0.0] > at com.denodo.vdb.util.introspectionservice.actions.ListJDBCSchemasAction.execute(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.util.introspectionservice.LocalSourceIntrospectionService.listJDBCCatalogAndSchemas(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.DescJDBCSourceAction.exec(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.Action.run(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.processor.VDBActionProcessor.a(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.processor.VDBActionProcessor.d(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.processor.VDBActionProcessor.a(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.Action.start(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.ExecutionEngine.execute(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.interpreter.execution.ExecutionEngine.execute(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at com.denodo.vdb.vdbinterface.server.QueryExecutorImpl.executeStatement(Unknown Source) ~[denodo-vdp-server.jar:7.0.0] > at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source) ~[?:?] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_162] > at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162] > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361) ~[?:1.8.0_162] > at sun.rmi.transport.Transport$1.run(Transport.java:200) ~[?:1.8.0_162] > at sun.rmi.transport.Transport$1.run(Transport.java:197) ~[?:1.8.0_162] > at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_162] > at sun.rmi.transport.Transport.serviceCall(Transport.java:196) ~[?:1.8.0_162] > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) ~[?:1.8.0_162] > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) ~[?:1.8.0_162] > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683) ~[?:1.8.0_162] > at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_162] > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) [?:1.8.0_162] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162] > 12152454 [RMI(1098)-10.219.54.69-58] FATAL 2018-05-31T15:02:24.253 com.denodo.vdb.interpreter.execution.Action [] - ***** ERROR REPORT ***** > 12152454 [RMI(1098)-10.219.54.69-58] FATAL 2018-05-31T15:02:24.253 com.denodo.vdb.interpreter.execution.Action [] - Time: Thu May 31 15:02:24 EDT 2018 > Action: com.denodo.vdb.interpreter.execution.DescJDBCSourceAction > Statement: DESC SOURCE JDBC DATASOURCENAME=dapedevl2 LISTSCHEMAS > User: admin > Database: test > Trans. mode: 1
user
 Edited on: 25-06-2018 19:08:12 -0400
Hi, Looking at the log error information, I think the error is because of a driver not being updated or referenced correctly. Here are a few things I would check: 1. [This ](https://community.denodo.com/docs/html/browse/7.0/platform/migration/export_the_metadata_of_the_current_installation) guide was followed for exporting the metadata. 2. Making sure the drivers and metadata was imported correctly as referenced [here](https://community.denodo.com/docs/html/browse/7.0/platform/migration/import_the_metadata_to_the_new_installation). 3. If the above was done succesfully, go to your data source and look at the "Driver Class Path" under the *Connection* tab. Make sure that the Driver Class Path is not the location of your previous installation db driver, but the new updated location path after the migration. In 7.0, you can optionally use a driver alias folder for the Driver Class Path, for example, 'db2-9' instead of listing the updated driver path in its entirety. Hope this helps!
Denodo Team
05-06-2018 19:36:05 -0400
You must sign in to add an answer. If you do not have an account, you can register here