CubeSQL feedback

Anyone using CubeSQL from SQL Labs?

What are the benefits compared to mySQL? Is the company still alive? They don’t reply to emails.

Your whole database is in a single SQLite File…

And that is all. An http bridge to a SQLite database. License is per server so it is not meant for distributable apps. Unlimited conections (in a single server) for $599 is expensive

Valentina Server also offers an SQLite Server. The benefits of Valentina are:

  • a clear license
  • I made a pkg installer
  • I have a nice interface for the server

Valentina allows you to distribute the server. It’t not cheap by all means but better than cubeSQL.

dude you don’t know what your talking about, cube sql makes CONCURRENTS acess to sqlite

they made a release recently, downloaded it, tested it some time ago, was cool

@Marco_Bambini could reply better

as valentina it is proprieatory database format, not sqlite.

edit : it is now

And exactly where I said thait it did not have CONCURRENTS access to sqlite?

But ok, I will be more specific:

It is just an HTTP server that allows CONCURRENTS access to an SQLite database FILE.

No matter how cool is the front end, the back end will be an SQLite database FILE, a technollogy that is not meant to be used as a server.

I used many years ago, User wanted “only” 3 clients, when changed, he didnt want to pay for the extra CONCURRENTS connections in the server. I was lloking at that when he talk about replicating it on more locations with posibility to grow on all of them. It was obvious that the $599.00 per site for unlimited CONCURRENTS connections was not going to work. At the end, I spent some days migrating the app to MySQL.

Also looked cool and easy to setup as a solution to redistribute it alongside a comercial app, but that $12,000/year for a Redistributable License was not going to happen.

That’s the reason I recommended Valentina Server with the SQLite option.

Valentina Server itself is a robust database.

If you want to share a SQLite database I’d suggest creating an application server that exposes an API rather than using either cubeSQL or Valentina. The application server and the SQLite database file should be on the same machine.

Quoting from the SQLite website:

With this pattern, the overall system is still client/server: clients send requests to the server and get back replies over the network. But instead of sending generic SQL and getting back raw table content, the client requests and server responses are high-level and application-specific. The server translates requests into multiple SQL queries, gathers the results, does post-processing, filtering, and analysis, then constructs a high-level reply containing only the essential information.

1 Like

I use CubeSQL since it lets me:

  1. start with the user data locally in SQLite
  2. fully silo each user’s data
  3. transfer the SQLite database to my host for multi-user access
  4. transfer the SQLite database back down from my host for a return to single-user access
  5. works across Desktop, Web and iOS using SQLDatabaseMBS
  6. store certain database fields as files (eg user PNG avatar) to reduce database size and speed backups
  7. all with one connection parameter and no coding changes

I find MySQL the most friendly, PostgreSQL the best for royalty-free deployment, but CubeSQL was best for my specific need. Once I paid for the $599 licence you never need to pay again (unless you want updates, which is very rare).

I get OK response speed from Marco over email (~ 24 hours).

2 Likes

since I have the requirement to move from single user and multiple user in one second, my application using CubeSQL for the last 15 years.

As for the price, I usually got them when they are on yearly sales

I don’t have an database corruption either

Marco respond very quickly to all my queries.

It’s not a mere bridge. It is a DBMS server engine on top of a DB engine. It manages a lot of features that a pure SQLite doesn’t.

Even the now defunct Studio Stable had at least Session Control and queuing.

We used Cube for over eight years, with multiple users accessing four databases, and never had a single problem. Extremely easy to set up. One of the databases had millions records and with multiple users accessing it at the same time there was no degradation in response time.
In those eight years Marco responded within 24 hours to our questions all but once. I’d give his support an A.
We moved to Postgres based on Norman Palardy’s (ex Xojo employee) recommendation. It’s free, widely used, simple license, and with many well written tutorials on the web. Not as easy as Cube to set up but still pretty easy.

I made a mydatabase class, that deals with replicating all xojo database class methods, but that can select to access a local sqlite file, or a postgres or a mysql server.
once setup, it’s very simple to use, and very quick to change from local to network user
you can even implement features like movetorecord that are not implemented by all xojo databases.

is it a product that you sell?

sorry no. I’m always modifying it, and even if it suits my needs completely, it’s not ready to use for other persons.
anyway, it’s quite easy to make, just make it slowly, for each new need you have, and it’s a perfect exercice to understand xojo database managment

This is possible with an API as well because you could include the class(es) that implement the API in both the server and the client and then just have a property that determines to which requests will be routed.

The other advantage of an API is the potential performance increase gained from the reduction in network traversal because you’ve moved the logic to be on the same PC as the database.

what if you don’t have internet access, would you be able to use the API way??

CubeSQL also uses an API Consumed by the plugin to access the SQLite file…

API <> internet

I have no idea how to do that… about api with sqlite… where can I find information??

As an example of how you might implement an API …

Let’s say the below represents a sales order contained within a JSON object ready to be submitted to an API that exposes the method named “newSalesOrder”. The API would do the job of parsing the order’s contents (which is within the “params” element) and updating the relevant tables in the database.

{

    "method": "newSalesOrder",

    "params": {
                "customer": "ACHME001",
                "customerReference": "PO1234",
                "orderReference": "2301-001",
                "billTo": "ACHME001",
                "orderItems": [
                    { 
                        "partCode": "WIDGET001",
                        "quantity": 1000,
                        "price": 25.00,
                        "perQty": 1,
                        "deliveries": [
                            { 
                                "deliverTo": "ACHME001",
                                "requiredDate": "2023-01-31",
                                "quantity": 1000
                            }
                        ]
                    }
                ]
            },
            
    "id": "ABC123"
}

So your API would have a router function that receives all incoming requests, that function uses the “method” element of the JSON to determine which of the API’s internal functions the value(s) in the “params” element needs to be passed into.

The “id” element is used to match requests to reponses so your API should include that in its reply.

If you implemented this using a database server you’d have multiple trips across the network …

  • Update the order header table - check response
  • Update the order line table - check response
  • Update the order delivery table - check response

The more lines/deliveries there were in an order the more trips back and forth across the network.

But with an API you can send it all encapsulated in a JSON object so you only have one request and one response. Plus you can include your API class(es) in your client app so you can easily switch from single user to multi-user too.