Mystery Msgbox....

[Jenny Peters]

I'm cleaning up a DB for a company and the previous programmer has done a trick I can't figure out...

When using the save button on a customer form, a custom dialogue box appears asking me to enter the customer number, if left blank.

Where is this dialogue box comming from?

Easy right?

Wrong! There is no code initiating this dialogue box anywhere. And I mean anywhere!

It's not on the save button click event, nor any other event on the form or subform, or the customer number textbox itself. There is no default value suggested for this textbox. I did search on the error phase in the whole VBA project and macros and nothing appears.

The tblCustomers has no default value for this field.

What's more, this message is triggered on a refresh or navigation.

And no, there is nothing in OnCurrent.
And no, there are no hidden modules or code...

What's more, similar dialogue boxes appear for other missing info on other forms as well when trying to save. This is no isolated case!!

After all these years, have I really missed something easy?

Please help!!

Jenny

 

[casey]

Can you set a breakpoint in the OnClick Event or is there no code for that either?

Just a thought.

 

[WayneRyan]

Jenny,

If you have the form in Design view, and click on the code
icon, is there any code at all?

There must be some code.

Wayne

 

[Jenny Peters]

Thanks for your responses...

But alas, I have found the answer...

As this DB is an Access Project, which is using SQL Server as a backend, the tables have a 'trigger' option that allows for further data verification.

By right-clicking on the table in the object view, I can add, edit, and delete these triggers.

The previous programmer seems to have used these all over the place.

Thanks for your responses though. They helped me find he answer!

Jenny

 

[Pat Hartman]

Triggers are actually the best place to perform these edits. Your predessor did a good thing.

It has always been a problem for me that Access doesn't support triggers. The reason that triggers are the best place to perform edits, is because it doesn't matter where or how a table is updated, the trigger will prevent bad data from being saved. RDBMS' work in such a way that ALL data updates go through the database engine. That includes Access. Access uses Jet as its database engine and all updates to Access tables go through Jet. You can do processing similar to that of a trigger in a form's BeforeUpdate event. But the problem is that if the table is updated directly or via a query or a different form, etc. the code behind the standard update form will never be executed and so the edits will not be performed. This of course leaves a gaping hole in Access' data integrity.

 

[Jenny Peters]

Yes, I agree. I end up spending more time trying to cover every possible scenario to stop users sneaking in bad data, than just programming the DB features...

Maybe Access 2003 will bring forth this well needed feature... just maybe...

Jenny