Best practice

[endri81]

Hi
I have a tabbed form with controls directly placed on pages without using sub forms or separate forms for each page.Is it necessary to place a save button in each page for saving data entered?Which is the best practice to save records in this case if data entered in every page belongs to the same record(person).It is very important for the records to be saved correctly

 

[pbaldy]

The record will automatically try to save if you navigate to another record or close the form. You don't need to explicitly save unless you need it saved for something being done mid process (like running a report that depends on that data).

 

[missinglinq]

The thing you have to keep in mind, in using a Tabbed Control in this manner, is that the controls you place on the Tabbed Pages are treated no differently than they would be if they resided on the "main" part of the form!

A control on a Tabbed Page, for instance, named MyTextBox, is referred to as Me.MyTextBox. You'd refer to its value as Me.MyTextBox.Value, and set focus to it with Me.MyTextBox.SetFocus, just as if the Tabbed Page didn't exist..

The Tabbed Control is really nothing more than a convenient way of formatting/organizing the display of data on a form.

Controls on Subforms that reside on Tabbed Pages are another story entirely and have to be handled differently.

Linq ';0)>

 

[gemma-the-husky]

further to the above, it is generally somewhat unusual to need a save button on a form at all. it may even function perversely, if a user tries to save unsaveable (incomplete) rows.

it comes back to understanding what a database is. its not like excel, where any cell can contain any data. its more like a very limited spreadsheet, where each column is strictly limited to the type of data it can contain, and where each row is handled as a complete entity. and once you move off a row, (by moving to a different row, or by closing the form or table) the row is automatically saved - (unless the data is invalid for some reason) - hence there is generally no reason to explicitly save a row.

note also, that once the row is saved, the data entered can no longer be undone. - again unlike a spreadsheet.

further it is most important to realise that a database table does not intrinsically have an order. the concept of next or previous row (as often used in excel formulae) is not generally logical for a database table.

 

[missinglinq]

Dave's right on the money with his 'further' comments. While there are a few situations where a 'forced' save is necessary in Access, I can't really think of any where the user should have to trigger this by clicking a button. Also, having a 'Save' button may mislead the user into thinking that a record won't be saved unless the button is clicked. They may change their minds about the saving the record, close the form or database, and assume the record has been dumped, when Access has, in fact, automatically saved it!

Linq ;0)>