"Null Pointer Exception using Read Database on jdbc:mysql"

Unknown

I've had some good experience using <READ CSV>
and having a quick right-off-the-box impression what
the dataset's AVG & STDDEV might be including some
basic buble charting is basicly all, what I need.

Now I wanted to move to MySQL and seeing it's supported
via jdbc driver made me believe it could be that easy like
reading CSV files.

But using the <Read Database> Operator from RM 5.0.009
results in java NULL POINTER exception. As logged here:
--
Aug 7, 2010 7:38:46 PM INFO: Executing query: 'SELECT * FROM `test`'
Aug 7, 2010 7:38:54 PM CONFIG: Connecting to jdbc:mysql://localhost:3306/test as root.
Aug 7, 2010 7:38:54 PM CONFIG: Connecting to jdbc:mysql://localhost:3306/test as root.
Aug 7, 2010 7:38:54 PM CONFIG: Connecting to jdbc:mysql://localhost:3306/test as root.
Aug 7, 2010 7:38:57 PM SEVERE: Process failed: operator cannot be executed. Check the log messages...
Aug 7, 2010 7:38:57 PM SEVERE: Here:           Process[1] (Process)
          subprocess 'Main Process'
      ==>   +- Read Database[1] (Read Database)
Aug 7, 2010 7:38:57 PM SEVERE: java.lang.NullPointerException
--

I also tested <Stream Database> which did produce results.
Some Meta information and the data view worked as expected
using small tables like `test` from  jdbc:mysql://localhost:3306/test.

But no AVG/STDDEV & CHARTS for tables with row count
130.000 from my own  jdbc:mysql://localhost:3306/e3_1.

more detailed information:
- db source  jdbc:mysql://localhost:3306/test &
  db source  jdbc:mysql://localhost:3306/e3_1 was tested via
 different ways and allways performant & fully functional.
- Database Connection was tested successfully from RM
- used bundled 5.1.9 vs. newest mysql-connector-java-5.1.13
- running on windows xp64 3.8GB vs. 7.8GB ram
- Using RM 64Bit
- started via RapidMiner.exe or launcher.jar
- using bundled JRE vs. most current JDK SE (build 1.6.0_21-b07)
 Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)
- different SQL statements like:  SELECT * FROM `test`;
- different SQL statements like:  SELECT COUNT(*) FROM `test`;
- different SQL statements like:  SELECT 7 as num;

When the "run or resume current process" button is hit, RM starts
to import data while consuming more and more memory as reported
by RM's System Monitor. When peaking, the Error Message:

--
The Setup does not seam to contain any obvious errors, but you should
check the log messages or activate the debug mode in the settings
dialog in order to get more information about this problem.

                                                                                                     | OK |
--

Any hints or suggestions?

--
Best Regards
Mike

Unknown

Well,

Problem solved.

Using the 32 Bit Ingres bundle: rapidminer-ingres bundle-5.0-install.exe
which is by the way RM 5.0.003 and running it using launcher.jar from:
--
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)
--
.. works just fine for me. :-)


It looks like <READ DATABASE> from RM 5.0.009 is broken.
Tested & reproduced in installer versions 32Bit.EXE & 64Bit.EXE
& stand alone .ZIP.

Also 15 Operators from Import/Data(16)/ are grayed out
in all 3 versions, leaving only <READ CSV> in full color.

The break occured between RM 5.0.008 & RM 5.0.009.
I'm using RM 5.0.008 now. Selecting data by table
& via SQL works with Operator & Process compatibility
level set to 5.0.008.

Hope it helps.

Beste Regards
Mike

haddock

Well spotted, Mike!

Yep, after upgrading to 5.009,  predefined connections on MSSQL  2005 test as OK but fail in the read database operator.

Thanks again for the heads-up.

fischer

Aargh. Confirmed and fixed. We'll make 010 as soon as possible.

Sorry,
Simon

fischer

Hi all,

5.0.010 is there, which resolves this problem. Sorry for the inconvenience.

Best,
Simon

dragoljub

Great work guys! Read CSV works much better, although for tab delimited files its still tricky to setup with the wizard. I stick to the basic settings to avoid processing a lot of data on the flly. Maybe there could be a 'process' button in the wizzard that starts data reading after the settings are made rather than updating on each change (for larger files).

Thanks,  ;D
-Gagi

Charles54

I had the same problem with READ DATABASE (ODBC Bridge) after upgrading to 090. Upgrading to 010 did not help. However downgrading to 008 eliminated the problem.

fischer

Hi,

I suspect that is another issue. The ODBC bridge has another NPE problem which is unrelated to RapidMiner. Could you post a stack trace?

Best,
Simon

Unknown

I lately switched to 5.0.010 and wanted to confirm,
that this issue is solved.

Thanks,
Mike

THW_Mark

I don't know whether it is related, but i just submitted a bug by email about a somewhat similar issue. For some reason, i cannot read MDB (Access) files in the latest 64 bit version of Rapidminer. The 32 bit version however, works like a charm. (except for the memory constraints ofcourse)

fischer

Hi,

thanks for reporting. This is an inexhaustible source of eternal joy. Please make sure

- Your Windows version is 64 bit
- RapidMiner is 64 bit
- Microsoft Office is 64 bit
- The ODBC driver is 64 bit
- The OBDC driver is installed in the first place.

If that is the case, please post again.

Best,
Simon

THW_Mark

Simon, thanks for your reply. Just for the sake of documentation for future users:

Most of the applications/drivers were installed, with the exception of 64-bit office. I assumed that for accessing the mdb file, it was not nessecary to have a 64 bit office suite, just as long as the 64 bit database drivers are installed. upon further research, i found the microsoft access database redistributable (available here: http://www.microsoft.com/downloads/en/details.aspx?familyid=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en )

Unfortunately, the 64 bit database driver apparently cannot be installed while there are 32-bit components of microsoft office on the machine. Microsoft just doesnt support 32 and 64 bit side-by-side. Therefore, it might be easier (and faster) to just dump the contents of the mdb file to another database. (In my case, mysql)

fischer

Thanks for documenting this!