alternatives to Firebird: sqlite [was: Firebird doesn't support MSVC 2015]

Lionel Elie Mamane lionel at
Thu Mar 10 08:51:14 UTC 2016

On Thu, Mar 10, 2016 at 01:27:46AM +0000, Wols Lists wrote:
> On 09/03/16 18:06, Lionel Elie Mamane wrote:
>> On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
>>> On Tue, Mar 08, 2016 at 08:44:03PM +0000, Wols Lists wrote:
>>>> On 08/03/16 13:32, Lionel Elie Mamane wrote:

>>>>> At this point, I'd say, even more strongly than usual: the one
>>>>> that will do it will decide. Upgrading to a modern Java-based
>>>>> database would maybe not be that bad after all...

>>>> Sounds like I'd better get my finger out then!

>>>> IF I can get the basics in place (and to be honest it is a big
>>>> if), are other people prepared to muck in and help with the bits
>>>> I can't do?

>>> Now, specifically, duckduckgo-ing for "Pick" does not bring the
>>> expected results, so if you could give me some links to see what
>>> you are talking about? Thanks.

>> Found
>> which sent me to "MaVerick" which led me to

>> I see that it can act as datastore for MySQL and PostgresSQL; this
>> gives the impression that it is a datastore, but there is no SQL
>> layer. What do you intend to use as SQL layer? Develop one?

> Pick, now generically known as MultiValue, is an n-dimensional
> database, and can be shown to be a proper superset of relational.

Sorry to be blunt, but as long as it can be used as relational through
SQL in a way that is close to the consensus of "the usual suspects" of
relational SQL databases, it is acceptable. If it is better, but
different, I don't think it is a good match for Base, an application
and framework built around SQL.

If it can do more, but we can use the "relational SQL subset"
reliably, then fine. But we *do* *need* to address it through SQL, not
some other API/language that is more general.

> So. My plans. Implement a string class (...). Implement the data
> store (...)

> On top of that, an integrity layer that enforces datatypes. (...)

> On top of that we'll need a Pick shell, and a SQL shell.

You mean none of these is done yet? That looks like something for a
somewhat distant future (on the scale of LibreOffice releases), then.

So on the LibreOffice side, we should probably use something else in
the short term. When your thing is ready, we can integrate it.

As I wrote previously, we can offer the choice between several
embedded formats.

> I'll then need a Basic compiler. (...)

> The wikipedia page (what else :-)

I didn't go see a page about an "operating system" when looking for a


More information about the LibreOffice mailing list