[Info-vax] Is there currently a functioning link for hobbyist licenses?

[seasoned_geek]

As far as SQLite3 in the embedded world, when used with something robust like Qt which has a lot of really nice C++ classes for manipulating cursors, etc. it's da-bomb.

I would not consider it for a multi-user system or anything which required multi-user access.  It has "fake" multi-user access meaning you have to lock before you do something and unlock when done. While you have lock nobody can do anything, but yes, you can run your app and be SSHed into the embedded target with sqlite3 running and immediately do a select after having done something on the target to show your results.

There really is no concept of "type safety" or foreign key integrity.

MySQL used to exist on VMS, don't know if it still does.  If any OpenSource database were to be ported to OpenVMS today the logical choice would be PostgreSQL. It is a full fledged database with lots and lots of support tools, massive quantities of documentation, etc.

SQLite is really meant for single application stuff where you need something better than a single hash and a rigid interface. Yes, many applications will resort to using RMS indexed files, but this can be quite limiting, especially if this one time the user needs to select based on a column/field which isn't in any index. That is quite a bit of code in our 3GL of choice but the SELECT statement doesn't care. The SQL optimizer already has a bit of logic to deal with brute force walks. Applications using RMS have to hand code it every time.


As to "a place on VMS" that is pretty easy.

1) If someone is writing something to be released freely (OpenSource or not) and they need a data store with flexible access and third party supporting tools.

2) You need an in memory data store that has a high level of flexibility, not just a linked list.

3) You are writing an N-level distributed (be it across a cluster or via various Web/Internet locations) which will feed/pull data from some central service/application. Nobody gets direct access to the database. A published API for the service is how all "user" must access. This keeps the database secure and lets you swap it out for whatever better tool comes along. One also avoids license fees.

The "database" view of the world is a very early 90s design model. Having one massive database with hundreds, if not thousands of connections, any one of which could run amuck hosing things up has proven to be a bad idea time and time again. Vast amounts of resources are consumed during the finger pointing session which tries to identify the culprit. Heck I've seen one person go into what they believed was an inquiry screen to look something up then go to lunch without getting out of it only to come back and find out that screen locked the entire order entry database for maintenance.

As I pointed out in my SOA book, we are increasingly decoupling the application from the database, instead providing "data services" so such catastrophes do not happen. These services get access via TCP/IP sockets, MQ Series message queues, ACMS queues, etc. None of them has any idea how the data is stored. More importantly they don't care.

Yes, Oracle is aghast to hear they aren't the center of the IT universe, but it is true. During the 90s they had many believing it had to be an Oracle database using Oracle tools and Oracle this with Oracle that. Now, to protect ourselves from ourselves, we develop a data service, publish an API, perhaps even implement the API via publish/subscribe, and how the data is stored consumers neither no nor care.