How do I make a table undeletable.

[smsmail]

Hello,

We have a table has become very critical to our automated processes. How do I manage it? It should never be deleted unless it is deleted by an administrator. Currently, the table is vulnerable.

Thanks so much for your help!

 

[Olaf Doschke]

there is just one way: keeping it open on at least one workstation makes it undeletable, actually a much better way would be to put the data under the protection of an SQL Server like MS SQL Server.

Bye, Olaf.

 

[smsmail]

Thanks Olaf for you reply!

So, is it common to have a foxpro (DBF) table under the protection of sql server?

 

[JRB-Bldr]

You don't have a Foxpro table under SQL Server.

Instead it is not un-common to have a Foxpro GUI front end, 'talking' to a SQL Server data table within a M$ SQL Server. This data 'communication' can be done is a couple of different ways - Remote Views, SQL Pass-through, etc.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Smsmail,

Does the application also write to the table, or does the table only contain static data?

If the latter, making it read-only would be a simple solution.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[alvechurchdata]

If it's read-only you could also include the dbf in the executable rather than having it as a separate file.

Looking outside the Fox world, is there nothing that the network administrator can do to restrict the rights of some users to this file?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Flagging the file as hidden would prevent it from being deleted manually (or, at least, it would make it more difficult to do so).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

smsmail, I didn't mean to put a DBF under protection of SQL Server, there is no such possibility, but to use SQL Server instead of a DBF, as a replacement.

As JRB-Bldr already said it's not unusual to use a different database backend together with a VFP application, especially if you need more security and protection.

Bye, Olaf.

 

[Olaf Doschke]

Flagging a file as read-only just prevents write operations to it, not file deletion. And making it hidden is also only half a solution.

Not letting users know where data is is already quite good, you need to know process monitor to see where an application is using files and find the location of the data.

But real protection of a file only is possible through file access rights management. It's possible to only allow access to some application user only the application itself will impersonate. But the slightest failure, eg a getfile() dialog, can then allow the user of the applications to access the files the application can see anyway.

The best way is to not store such vulnerable and important data in DBFs.

Bye, Olaf.

 

[Auguy]

This might be to simplistic for your situation. If it is static data you could store a copy of the table in a secure location on the server. Then schedule (every 5 minutes?) a task on the server to check for the existence of the "Live" table. If it is not there, then copy the secure copy to the proper location. You should probably change the app to look for the table before tying to open or use it and issue the proper warnings and/or stop processing until the table is available again.

Auguy
Sylvania/Toledo Ohio

 

[smsmail]

Thanks all for your insight.

The organization that I work for is looking into the possibility of using SQL Server as a backend database. Not being a database expert, I have suggested it. I will be asking more questions in the future about this topic.

Yours Truly,
smsmail

 

[JRB-Bldr]

Just an associated FYI - not meant, in any way, to discourage the use of SQL Server, but merely to inform...

If your organization is small then you might be able to use the FREE M$ SQL Server 2005 Express.

http://msdn.microsoft.com/en-us/library/ms345154(SQL.90).aspx

However, if it is a larger organization with more users and/or has greater data capacity needs, then you will be looking at some expenses related to using SQL Server (server HW to install on, license fee, etc.).

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Smsmail,

I also don't want to discourage the use of SQL Server, but I wonder if we could look at this problem from a different angle.

Why is this table at particular risk of being deleted? What makes it especially vulnerable to accidental deletion?

I appreciate it's a critical table in a critical application, but that applies to most tables in most of the applications that we all write. In any of my own apps, if a table got accidentally deleted, the whole app would fail - at least until a backup was restored.

Before you start investing time and money in alternative databases, perhaps you should address the risks that this particular table is facing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Mike,

that's true. I didn't put this into question. But indeed in some way DBFs are just like any other document. Surely there is the risk of any file to be deleted, but in regard to Office documents companies also don't tend to do more than backups against the risk of the loss of documents.

Databases and tables of them surely have a different level of risk, as Office itself still runs if you delete documents, a databased application on the other side will be more depandant, even on less critical data.

Bye, Olaf.