>Hi all,
>
>I need some help with views. I am very familiar with tables and cursors, however, I am working with a new app that uses views. Basically, a connection is formed to a SQL database, and then a view is created from one of the tables in the database. While I'm connected to that database, what I want to know is, am I able to somehow "browse norm" in that view while my app(built as an .exe file) is running? Does it work the same as viewing a temp table or cursor? My program stops responding right after it creates the view. It tries to put everything from the view into a table (Select * from viewname into table tablename), and it just hangs there and nothing happens. So I'm trying to troubleshoot. Any help is greatly appreciated!!
>
>Thanks,
>erin :)

Usually a view is created to retrieve only a few records from the source table[s]. This is done by adding a filter to the view when it is created. You can even parameterize the view with a variable.

create sql view myview ... as select * from sometable where State = ?cValue

The next step is to open the view with no data:

use myview nodata

Next, set the value of the parameter and requery the view:

cValue = "TX"
requery("myview")

The requery retrieve all records where State = "TX" If you define the value of the parameter [e.g., State] before you open the view, you can omit the NODATA option.

When a view is opened, a temporary file is created in wherever the TEMP environment variable is pointing [make sure this TEMP folder exists]. All views use optimistic buffering [table buffering is highly recommended] and will show an exclusive use status. This applies to the temporary file only and NOT the source table. There is no limit on the number of users that can have the same view open. Your only conflict arises when you issue a TableUpdate() to send changes back to the source table.

You would only experience a conflict if different users are trying to update the same record. This update does not have to be at the same time either. For example, 2 users open the same view with some common records before any changes are made. The first user could issue the update and post the changes to the table. Some time later, the second user issues his update. The problem is the original values in the table were changed by the first user without the 2nd user's knowledge.

There are several VFP functions you can use to alert the second user of a problem -- GetFldState, OldVal, CurVal. Or you can just force the update and stomp on the first user's changes.

I recommend table buffering because if you use record buffering, an implicit tableupdate() is issued everytime the record pointer is moved.