Prevent Table from edit or amendment

[haj1503]

Hi friend,

I've difficult to prevent my user from edit my table, did you know how to prevent my table from amendment or edit?

I've tried to hidden my table but the user still can amend the data from table. I also have disabled my application from the user to press shift key. right now the user so tricky their just make new database which make a link table where their can make amendment.

I don't want to create the system workgroup because sometime difficult to upgrade to the application future.

Any suggestion so the user would feel frust when their want to make amendment.

Best regards,

 

[hermanlaksko]

I dont know why you want to prevent your users from inserting data into your database but you could set your database (back-end) to read-only using the attributes on the mdb itself, however this will disable the whole base.

Herman

 

[haj1503]

Hi hermanlaksko,

Actually I've the form for individual table which I need my users cannot make amendment unless input data just all, because if their can enter to the table, they maybe can make amendment.

and also if they can make amendment the information would return wrong unless the admin aware the amendment.

hopefully you understand what I meaning.

Best regards.

 

[hermanlaksko]

If you want to control your users from the form, witch is the way to do it (in my humble oppinion ) you can set the forms allow addtions, deletions, etc. to enable/disable the users options here.

Herman

 

[MichaelRed]

AS already noted, some details of WHY users are prohibited from data modifications is quite unclear. Further, the somewhat extreme measures which they use to make the modifications mentioned are beyond any normal situation. In general, users who even attempt to violate db security would be immediatly 'dismisseed' and in some cases further legal action might also be taken. So, the issues seems -to me- to be quite beyond 'programming' considerations only and into the broader arena of the nature of the business and the employees.

On the other hand, you dismiss the concept of db security as 'to much bother', leaving the impression that you intentionally present the issue in a manner of the paradox.

Then again there is some hint that while users should not be able to change the data, that 'somehow' the data does need to be (and is changed) on occassion - but the changes need to be brought to the attention of an administrative individual.

So, in summary.

You want the data to be 'locked' for many / most users, at least dome of whom are knowledgeable and capablble of working around most soloutions.

You cannot/will not use the MS. A. buiilt in security to limit access to teh data.

Some users need to be able to change the data - but there needs to be some controls on the changes so that the changes are presented to certain individuals.

Is the above correct?



MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[haj1503]

Hi Red,

I agreed with you, for your information, WHY I need to do like that because my current company need myself develop the application with MS Access. to be ensure that the application cannot to amendment from users, they need me to ensure that this will not happend.

How I need to ensure that my application cannot hack by the users to my management?

The matter that I arising actually will be happend then just why I arised here? I know and believed clever developer like you maybe can help us how to prevent that, did you agreed?

Anywhere see u soonest reply.

Best regards,

 

[MichaelRed]

Help? No. You have 'circled the wagons' much to tightly. and left no space for manuevering -or to get in or out of the area. It is -for me- a stalemate.

As to suggestions. I can off er only two:

1.[tab]Learn and implement the built in security. this is the better (only?) long term soloution. It is effective and would be a standard approach which other responsibe programmers can follow when you are 'promoted' to another position. It is well documented and can offer the data access control you need.

2.[tab]do not place the data in a table in the db at all. Make it be a set of literals (perhaps a UDT with the elements representing the table fields). Within the startup object, initallize the literals to the values necessary. Inform hte db users community that any / all changes must be acoomdate via a formally approveed request from the "administrative' person. Have that individual provide you with a signed hard copy of any / all required changes -which you would then manually implement in the code. Since the user community appears to be quite sophisticated, I would expect that at least some of them would be able to bypass even this approach if you leave the initalization in 'plain view' in a module in the .MDB. To circumvent their intrusion, you should make the initalization process into an MDE (compiled) db which is added as a reference to the MDB program. Further, the controls where the info is displayed need to be "locked" as a user may still change the immediate content. All references to the values need to be revised to the initalized values, as opposed to the table (or query) values. these measures will, in my opinion, be comprimized by determined 'hackers', but might provide a brief respite while you learn and implements the security. Making hte entire front end into an MDE db would help, and could possibly even be a much longer term soloution, as the hackers would then need to figure out where the source is and change that - but determined hackers acting from within the organization will probably do that at some point.

I would repeat and emphisize that violations of company policy re un-authourised changing of data should be a 'carrear decision'. (e.g. FIRE THEM on the spot.) Then, again, in your situation you will not be abloe to prove who alltered what or even when it was latered, so you will never have the information to even accuse any individual of the trespass.



MichaelRed
m.red@att.net

Searching for employment in all the wrong places