Protecting Tables

Creating tables and queries
Post Reply
rh205
Posts: 2
Joined: Sun Dec 23, 2007 1:58 am

Protecting Tables

Post by rh205 »

I am setting a database up for an organization, but wondered is there any way to allow people to enter data in to the table using a form but prevent people from deleting it or deleting the table.
User avatar
r4zoli
Volunteer
Posts: 2882
Joined: Mon Nov 19, 2007 8:23 pm
Location: Budapest, Hungary

Re: Protecting Tables

Post by r4zoli »

If make Form with wizard in step 6, you could select the data entry mode:
Form_wizard_6.PNG
AOO 4.0 and LibO 4 on Win 8
Hungarian forum co-admin
User avatar
Villeroy
Volunteer
Posts: 31269
Joined: Mon Oct 08, 2007 1:35 am
Location: Germany

Re: Protecting Tables

Post by Villeroy »

Database servers like MySQL, postreSQL, MSSQL or standalone HSQL support fine grained user privileges for users and groups. A Base document prompts for a log-in when connecting to such a server. The embedded hsql does not support this. The first user opening the Base file has full access. Any further user opening the same Base file has read-only access. If you are setting up a database for an organization, you may consider utilizing a database server with concurrent access, user privileges and Base as one possible frontend among others.
Please, edit this topic's initial post and add "[Solved]" to the subject line if your problem has been solved.
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
wurzel
Volunteer
Posts: 145
Joined: Sun Dec 09, 2007 10:39 am

Re: Protecting Tables

Post by wurzel »

rh205 wrote:I am setting a database up for an organization, but wondered is there any way to allow people to enter data in to the table using a form but prevent people from deleting it or deleting the table.
The only real way to do this with an embedded HSQLDB database in an ODB document would be to make the file write protected at OS level. Otherwise, the user can always unzip the ODB file and physically delete the table and creation script information that is stored within the ODB document. Of course, even here, the user could always make a local copy of the ODB file (assuming you are working from a server), change the file to its heart's content, then reload the file back onto the server, squashing the file already in place. Again, this is up to your systems admin to make sure that users can't do this sort of thing if it really is that important to you.

Another way would be to use a separate form outside of the ODB document for data visualisation and make that read only. Create your form within the ODB and then save it under Save as.... Then close the ODB document and just indicate the link to the form (Writer document) you've just created. Even here, you have to make sure that the form is read only, otherwise your user can gain access to the form setup and edit its properties, potentially screwing things up again.

Alex
Post Reply