Yeah, there's no way to block ctrl-alt-del without getting pretty heavily into windows programming. It's sort of like asking how you can make it so that turning off the computer won't close the form--it's just happening at a lower level than that on which Access operates, and Access won't be able to stop that.
On the other hand, if people are doing this regularly and it is causing problems with your data, there are two angles I would investigate.
1) This one may sting a bit, but the question here is, are people doing this because they are getting frustrated working with your forms? If people are feeling the need to do something that is so likely to make their PC unstable, is it possible that the form is putting an onerous burden on the users? Clearly I have no idea what your form is like, and it may well be small, quick, and easy to use. But this is the first thing I would think to check into.
2) You could make the form and unbounded form. This won't prevent users from closing the form, but it will prevent the closing of the form from doing any harm to that particular table (or tables, if it's based on a query).
Unbound forms are very powerful, but a good bit of work. You may already know your way around them, but for the benefit of anyone reading this who doesn't, here's a (tiny) explanation.
Bound forms have a RecordSource, a table of query where they get their data, and each control on a bound form has a ControlSource, the name of one of the fields in that RecordSource.
When you move from record to record, Access knows where to get the data to display for the record because of the bindings. Also, because it knows how to display info, it also knows how to save it back to the table. This allows it to automatically save a record every time you move to another record.
Unbound forms have no recordSource, and their controls have no ControlSource. This means that you have to do the displaying and saving of records in code, and navigating from one record to another, too.
When you go to a new record, or open a form and display the first record, your code creates a recordset that retrieves the data for that record and puts the data from each field into the appropriate control. Saving is done manually, too. If you want to save a record you do the whole thing in reverse: make a recordset and save from the controls to the recordset.
This arrangement means a few things. You have to make your own navigation buttons. This is more work, like everything on an unbound form, but it allows you to control such things as whether or not saving will happen--you can just do it, or, if you want, you can prompt the user to find out if she wants to do it.
It also means that you can put an explicit "save" button on your form, which lets the user feel a little more in control.
But the biggest advantage, by far, is that if someone kicks out the powercord while your user has this form open, and the record half filled out, and some gibberish in the current field because it hasn't yet been evaluated to check if it is valid, nothing bad will happen to your tables. In fact, nothing will happen to your tables at all, because kicking out the power cord doesn't call the code you've written to save the record.
OK, so it got a little longer than I thought it would be, but there's a short take on unbound forms.
Hope it helps.
Jeremy =============
Jeremy Wallace
Designing, Developing, and Deploying Access databases since 1995.
![[thumbsup2]](/data/assets/smilies/thumbsup2.gif "[thumbsup2] [thumbsup2]")
