[Info-vax] VMS databases

[Jan-Erik Söderholm]

Den 2023-11-19 kl. 18:37, skrev Stephen Hoffman:
> On 2023-11-18 14:22:52 +0000, Arne Vajhøj said:
> 
>> On 11/17/2023 8:10 PM, Arne Vajhøj wrote:
>>
>> Niel Rieck replied (for some reason the post did not propagate to 
>> eternal-september, so this is a manual copy from Google Groups):
> 
> Probably caught in the Google Groups spam.
> 
>>>  Two additional points.
>>>
>>>  1) I've done a bit of hacking with SQLite (on both OpenVMS + Linux ) 
>>> and can inform that it should only be used in single user applications. 
>>> When any process issues an "update table" command, all other processes 
>>> are locked out.
>>
>> For multi user scenarios database servers are usually better than 
>> embedded databases.
> 
> As with many things in IT, that depends.
> 
> Expectations and related sizes can also differ. What can be considered a 
> small database for SQLite can potentially be considered a large database 
> for OpenVMS, for instance.
> 
> Expectations? SQLite tops out at 256 TiB databases, while OpenVMS file 
> storage tops out at 2 TiB files absent 'heroic' efforts.

A single Rdb database can have 8192 storage areas (individual files)
so the max database size would be something like 16.000 TiB.


> 
>> I would have thougth SQLite could only have locked some part of the 
>> database when doing an UPDATE, but ...
> 
> If you ask nicely, SQLite will defer the locking until the commit:
> 
> https://sqlite.org/cgi/src/doc/begin-concurrent/doc/begin_concurrent.md
> 
> Otherwise, SQLite picks a simpler approach to database locking, permitting 
> one concurrent writer.
> 
> That section also includes suggestions around how to arbitrate update 
> access from within the application, when (if?) that becomes necessary.
> 
> 
>