Assuming MySQL V4 with INNODB support, should this work? More importantly, does anyone have it working with Servoy 1.2 on Linux (using default DB driver)?
Reason for asking is that I installed Servoy 1.2 on Linux (Debian “Sarge” snapshot) and got the dreaded “The repository server must run on a SQL database with support for transactions!”
Anything else I should be checking, other than that I really did configure INNODB support?
Thanks,
Neale.
Neale,
take a look at the following topic for some tips:
http://forum.servoy.com/viewtopic.php?t=302
Cheers,
pieter
Thanks Pieter - looks like “default-table-type=INNODB” is the crucial missing magic.
If that’s the case I’m tempted to speculate that Servoy’s requiring a change in MySQL’s default behaviour is, at best, a mis-feature.
It will be interesting to see if any of the other issues there are still hanging around.
Thanks,
Neale.
Why we need to change the default behaviour of mysql is pretty simple. In the default behaviour MySQL is not really a database.. It is just a storage system. Because in my eyes a real database system must support transactions. And you really don’t want non transaction support repository then you will have many other support questions.. believe me..
Setting the default table-type to InnoDB was insufficient (and the setting really was verified in MySQLs SHOW VARIABLES).
But, leaving that set AND downloading the latest stable JDBC driver from mysql.com results in success (or at least lack of errors)
Why does the Servoy Linux installer ship with an old MySQL JDBC driver???
Am I likely to have broken anything by doing this???
Neale.
I think i have posted this before in another thread
we can’t ship the new 3.0 driver (at least we think we can’t it is still very vague) because the 3.0 driver is GPL.
So yes you have to download it youre self. And there shouldn’t be any problem doing that.
I’d have thought you could ship a GPL driver (especially with source too; what you definitely mayn’t do is “derive” your non-GPL program from the GPL driver - which shouldn’t be an issue here). Any idea of what’s the potential conflict with the GPL?
Regardless, perhaps it’d be a really good idea to hang up the metaphorical “beware of the leopard” sign on the package with the old driver and provide a conspicuous pointer to the current driver?
Regards,
Neale.
I talked with the maker of the driver themself about this, and he was also very vague and he couldn’t tell me that i could ship the driver..
So we are wary to do that..
But the old driver should work fine by the way..
OK, I mightn’t understand the issues but I do understand the prudency of taking the conservative path.
Re the old driver: No, it did NOT work for me. Specifically, I was plagued by the “The repository server must run on a SQL database with support for transactions!” error till I upgraded to latest stable JDBC driver (from the one distributed).
Regards,
Neale.
I have looked into this matter a few months ago because I was developing a db application. From what I read it should be possible to ship the driver.
I don’t know the correct wording anymore but as long as MySQL is not the only database your application depends on they don’t ask for payment but do want you to tell them that you ship.
On the other hand, the PHP dev team also decided to drop built in MySQL but this might be because they only had MySQL support as a built in db feature…
i had a personal discussion with the maker of the jdbc driver itself back then when they released 3.0 under GPL (instead under LGPL) and he him self couldn’t be clear what i was allowed to do.
So we will not take any risks..