Mango can read from an external database using the SQL data source. Out of the box it can connect to a MySQL database, but others can be implemented by finding the appropriate driver (usually just a jar file that you can add to WEB-INF/lib).

If you are on a Windows platform, it is possible to use an ODBC/JDBC driver to connect Mango to and ODBC data source. In Windows you can then set up various things - like flat files, Excel spreadsheets, Access databases - as your ODBC sources. Might be worth a try. By finding the appropriate drivers (which are typically easy to find), you can also connect Mango directly to Oracle, MS SQL Server, Postgres, etc.

Your alternative to having a database intermediary is to connect directly to your A/D converter processing board, assuming it supports some communications protocol like Modbus, BACNet, 1-wire, etc. Do you know?

Once you've decided on a connectivity strategy, i can help you with the details.

First of all, Thanks for your clear explanation.
I´m not sure I should change to another subforum, but the following topic naturally comes to me . :roll: The idea is connecting Mango to an own developed A/D converter processing board, controlled by a set of Visual Basic routines, which can put data on the hard disc in any standard file formats.
Which could be the proper way to implement the SQL Data source for Mango ?. I mean, should/can Mango read an external database, or I must put data into native Mango's database ? In both cases, which is the appropriate mechanism (script, event driven routine, scheduled task...)
I tried finding examples in other subforum, I saw http://store.qkits.com/moreinfo.cfm/K8061 board and their uses, very interesting :shock: Did you write some work notes to implement such a functionality (tables names, record format, data type ...)
My best regards.

Great to hear. Thanks for following up.

Regarding access to the Mango database, remember that Derby is a standard SQL database that happens to be implemented in Java, so there's no magic to it. However, in this case, the properties of Derby that make it especially useful to Mango are the same as those that will cause you difficulty in accessing it the way that you want.

A bit of background; skip this paragraph if you want. Derby has the ability to run "in process" with a Java application, so that you don't need to, for example, start your database process, and then start Mango; you just start Mango and the single Java VM runs everything. This greatly simplifies installation and operation, as well as improving performance since the in process mode makes DB connections into lightweight objects, which also makes connection pooling unnecessary. There is also a small security benefit since Mango has exclusive access to the database.

The problem in your case is that Mango has exclusive access to the database. If you want to get directly into the Derby tables, you first need to stop Mango, and then start a Java process that itself would exclusively access Derby.

However, there is a way to get to the database through Mango, but it's not pretty. Recall that there is a SQL menu item in Mango from which you can run arbitrary queries and execute updates. It would be possible to automate a process of logging in, executing queries, scraping the results, and then logging out. (Told you it wasn't pretty.)

Better alternatives would be either to build into Mango the functionality that you want, or to build something like a web service with which more natural M2M access to the data is made available. Sadly, at the moment we are swamped and so will not be able to get to this for some time. Any enterprising Java developers are welcome to take a stab at it though. :)

Ok, good, you already have it installed. When you start Tomcat you'll see references in the startup messages to the Java implementation that it is using. Ensure it is specifying your JDK 1.6 installation.

If it isn't, to get Mango to use the JDK you'll need to change whatever it is that decides what JDK to use. It could be explicitly set in your Tomcat start script, or it could be set in your environmental variables; you'll have to determine that yourself, but it should only be one of those two. Change it to point at the JDK 1.6 installation.

Once you're sure your Mango instance is using JDK 1.6, follow the instructions on the Mango download page to ensure that the RXTX files are in the correct directories and try again.

You need to use the JDK rather than the JRE. Can you try installing the JDK and using that instead? (Don't forget to change how Tomcat gets started up too).

I verified that the proper files were copied:
RXTXcomm.jar: save in <jdk1.6-home>\jre\lib\ext
rxtxSerial.dll: save in <jdk1.6-home>\jre\bin

Java version is Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Could be there some problem ?
Thanks for your patience.

Yes, the header.js calls the corresponding function in the common.js. I'm sorry, but I can't say what is going on because it works in every other instance of Mango that we run. I can only suggest that perhaps your browser cache is hanging on to an old version of the common.js file. To refresh, press ctrl+F5; hopefully that will correct the problem.

I searched and founded that function in C:\Tomcat 6.0\webapps\ROOT\resources files common.js and headers.js

Whats going on :?:
Thanks very much.

Did you upgrade from a previous version, or download 0.9.2 and install fresh? If you upgraded, can you try the upgrade again? Perhaps it didn't install correctly for some reason.

Two things:

1. Please confirm the version of Mango you are using. 0.9.2 should not have any references to javax.comm.*.

2. Errors like that or gnu.io* indicate incorrectly configured serial i/o. Please check the instructions on the download page.