🚀 go-pugleaf

JD wrote:


>>Why would you prevent access at the same timet ?
> 
> 
> Only prevent writing at the same time. 

Writing to the same row of a table ok. But do not
block a complete table or even worse the whole database.

 > It's a relational db of
> my own design that's super fast and has an extreemly small
> foot print and there's nothing (additional) to install or
> licence ect..

Heh why do we all build our own relational db ? Welcome.
Dit you implement some SQL-like features ?

>>I do not grab this. Clients would not read/write from/to a database
>>I would think, only your server.
> 
> That's how it *will* work in the future. The application was
> developed as a stand alone and as such, all of the code
> resides in what will be the client.

Well I can only advise you to make that your server. Then
make clients that can request tables or rows or communicate
by sql.

 > The demand dictates that
> the first priority is to get it working on a networked system
> for multiple users the fastest way possible.

If your original app has GUI and database well separated then
you can use the GUI for the clients.

>>How do you want to set up all this ?
> 
>     Ask server for permission to write
>     Wait for permission
>     Tell the server it's finished writing
>     Server tells other clients the data has changed

So the clients do all. The server does not know the database.
This is a possible solution indeed. Where clients should
have network permissions on a shared directory.

This solution is not suitable for clients in internet as
there the directory is unknown. So thats why I think
you should do all contact with the database by one databaseserver
only.

If a client askes the server for permission you better make
a blocking client. Once you have the blocking client receive/send
routines then the rest of the code will be easier then when using a non-
blocking client as then the client goes to rest after sending a request
and then has to wait for an event which brings the answer.

> I thought that I could handle this with a basic message with
> params that indicate which file (table) and record (key) were
> changed.

Indeed.

Hans.