>Hi, Erik,
>So, what is the point to have one view for viewing and one for updating? Think about it. My understanding is that views suppose to be more convensional way to gather data from different sources(tables) and allow program to manipulate data in such tables.

YOu are correct in that views make it possible for us to view data from different tables as if it came from the same table. The point in having more than one view, is that sometimes this is necessary to keep things simple enough to be manageable. Adding records to multiple tables is not only technically complicated, it is logically complicated. How do you know if the user wants to add records to all three tables at once? What if the user wants to add a new doctor, but to an existing region? What does a new view record actually represent?

The answersto these questions become clearer if you deal with each table as its own entity, and only use views to tie the dataq together for looking at. When a user adds a doctor to the table, he must decide if he is adding him to a new region or an existing one, if he will practice a new specialty, or practice one that already exists in your table. YOu can probably devise a way to handle all this in the same view, but from my experience the logic involved quickly gets so complicated as to be unmanageable.

"Something is ratten in Datch kingdom..."(:-)
>I asked the same question on this forum awhile ago. I'd like to learn more about views and be fluent on them. Could you, please, suggest something in my case?
>I have database where user suppose to enter new doctors practicing in some geographical area. I have three tables in database to keep data about them: Specialty, Doctors and Offices. All tables have foreign keys as a primary to identify each record. Their structure as follows:

It sounds like the main entity in your app will be the doctor. What you probably want is a way to list doctors, their offices, and their specialties and filter or order the list on user specified criteria. For this case I would normally use a 'doctor list' screen, with a grid that showed this information in list format. The screen would have Add, Edit and Delete buttons. The edit and add buttons would take you to a maintenance screen that allows you to change fields for a doctor.

To choose an office or specialty, a user would click or something to bring up a modal form with a list of available offices. The chosen office's id would be returned to the form and the name of the office displayed in the field. Same for specialty.

This kind of layout would demand three primary views (doctor, specialty, office, each with their primary key as the parameter), and two unifying views (one with the primary key as paramater, the other for a filtered list).

The doctor data entry screen would have to incorparate all three views, querying the main (doctor) view first ,and then querying the two child views with the keys returned by the doctor view.

The logic behind the scenes would populate foreign keys and requery as necessary.

This general layout is but one of many possible strategies, but it is the one I have found to be simplest (read: best) to implement. If you decide to use something like this and have further question, post them and I will answer as best I can. HTH.