Unbound form - detect when the change is made 1

[seaport]

I understand how to create an unbound data entry forms. But I am struggling to find an efficient way to detect the change made by a user in the unbound form, so the database can force the user to save the record. I have three options right now.

1. Lock all controls in the form and provide an "Edit" button. The user need to click the "Edit" button to unlock the form, and at the same time tells the database that changes will be made. It is a lot code to unlock/lock every controls.
2. Create “After_Update” event for each control in the form and that event procedure will detect any change made by the user. This also involves a lot of codes.
3. Create a local table that is exactly the same as the table on the Server. A record is copied to the local table from the Sever table when the record is loaded. The unbound form is bound to that local table. So I can use the Dirty event of the form to detect whether change is made.

Which option is best? Or could someone help me think outside the box?

Thanks in advance.

Seaport

 

[fneily]

database can force the user to save the record". In design view of the form, select the form (upper left corner,click in the square. A black square will appear). Bring up the property sheet. Click the ALL tab and scroll down to the Option CYCLE. Change it to Current Record. If the user makes a change and continues tabbing to the end of the tab order, it won't save. So, then you can create a command button that must be click to save the record.
Is that what you want?

 

[fneily]

Forgot to add - this way you can create a form with BOUND fields. But until they click the save button, it won't change any data.
With an UNBOUND, after the save button is click, you then can write a simple DAO code to save the record to the table.

 

[seaport]

fneily,

What you suggested is to let the user decide whether there is a need to save the data. This works most of time. However, without the detection of data change, there won't be a warning to remind the user. A user may go to another record or start a new record without saving the data, just like writting something in a web page form without clicking the "Submit" button afterwards.

Seaport

 

[TheAceMan1]

How are ya seaport . . .

Whats wrong with a form bound to the origional table on the server and using the [blue]Dirty[/blue] property in the forms [blue]BeforeUpdate[/blue] event as detection for your prompt. If the user selects [purple]No[/purple] to saving, the entire record can be rolled back with [blue]Undo & Cancel![/blue]

See Ya! . . . . . .

 

[seaport]

TheAceMan1,

The "bound to the original table on the server" approach does not work for me, because the backend database is a SQL server DB. Actually I have another thread for that:

http://www.tek-tips.com/viewthread.cfm?qid=1204540&page=1

Seaport

 

[fneily]

"A user may go to another record or start a new record without saving the data,"
The above statement is false for a Bound form. When they go to a new record or back to a previous or forward to the next, the data is saved.
Since, by your above post you want to use an UNbound form, why don't you just hide the Navigation buttons? In design view, bring up the property sheet for the form and change Navigation Buttons to NO. Then create your save button which they would have to use. You can also get rid of the Close button and create your own close so that when they close without saving, you can have a message box asking if they saved or not.

 

[TheAceMan1]

Roger That seaport . . .

I have a good Idea to give ya, but you post origination has an operational ambiguity that needs resolving.

Is the unbound form to be [blue]capable of saving consecutive records[/blue] ([purple]while the form is open![/purple])? . . . This would require a save button or the equivalent thereof, which defeats your purpose of forcing a save . . .

Then on the other hand, opening & closing the form each time to save a record is not user friendly (but can be done).

Your thoughts? . . .

See Ya! . . . . . .

 

[seaport]

Here is some clarification.

The unbound form has a dropdown list so the user can choose to load another record into the bound form. Surely I can program a warning "Do you want to save changes?" every time before loading another record. However, the user may have just viewed the record without making any change. So the warning should only appears if the database detects that there is a change.

The unbound form has a close button to close the form. Similarly to my above explanation, a warning can be programmed but the detection of change is also necessary.

Seaport

 

[TheAceMan1]

seaport . . .

[ol][li]If the form opens with empty fields, its easy enough to loop thru the controls looking for an data entry. On the first find you save in code.[/li]
[li]If the form opens and is updated (thru code) with data from a record, while the code is updating [blue]store the values in an array for comparison . . . (the array holds your initial values)[/blue][/li][/ol]

See Ya! . . . . . .

 

[seaport]

Hi, TheAceMan1,

I don't know why I never thought of your idea. Your idea of using comparison will work. Thanks.

I would like to consider your idea is the fourth option. Comparing to your idea, one advantage of my 2nd or 3rd one is, the data entry form looks more active because when a change is detected, the disabled "Save" button will be enabled. Anyway, that is a marginal benefit considering all extra programming work I have to do.

Seaport

 

[TheAceMan1]

seaport . . .

Put the Array in the [blue]Decalarations Section[/blue] of the forms code module, and be sure to subscribe a [purple]datatype of Variant[/purple] . . . (this way you can use [blue]For Each[/blue] to loop thru the controls without worry!):

[blue]Option Compare Database
Option Explicit
[purple][b]Private OldDat(0 To 5)[/b][/purple][/blue]

This makes the array present as long as the form is open!

[blue]For consecutive saves, just update the array before you save . . .[/blue]

The method eliminates your 3rd option as the additional table is not needed ([blue]your now handling records on the fly![/blue]).

As to the 2nd option . . . it depends on how you have the forms [blue]user reactionary interface[/blue] setup. In any case the method opens the door to your imagination! . . .

[purple]Cheers![/purple]

See Ya! . . . . . .