John,
Views are not but in its simple form can be considered as cursors. In a DBC a view only stores the SQL and some properties. To make it simple for you :

select fieldlist from myTable into cursor myVirtualView readwrite
cursorsetprop('Buffering',3,'myVirtualView')
*Edit
tableupdate\revert

Here nothing happens to MyTable and you've to update it manually. When it's a view it acts as a window to underlying myTable and updates (if allowed to update) myTable.

-If you wouldn't use the views for updating (readonly as you said) then cursors would do perfectly well.
-If you'd use views you only need to create them once (remember what you create is SQL definition + some properties which you might check by getting aprg version of your DBC with gendbc).
-If you need to create your views on the fly then you don't need to (and never do that) create them in your DBC. But a view needs a DBC. For on the fly views create a separate temp DBC and create your view in it. When done close an erase the DBC.


"1st, I am learning that CREATE SQL VIEW actually adds the view to the ITF database. I am doing this in my code. Seems that is not what I should be doing unless I only do it once during design, but not during runtime. I should instead just be populating the view or instanciating it or something."

As you should now have idea about it, yes create once.
To populate your view you just 'use' it (again remember it's SQL definition and runs the SQL behind the scenes) :

use ITFDBC!myView

If at any moment the data in base table (in our sample myTable) changes, your view would be outdated, to repopulate it call requery() function with view's alias :

requery('myView')


"When I start the POS app after it was completely shutdown, I get v_myview exists, overwrite y/n? I believe that is telling me it is already created even though it certainly does not exist in the way a temp cursor would."

I think you now know why. SQL definition is created in DBC as a record (oh well not just one record). As if it was a persistent table you get the message. It's not but it's a persistent definition.

"I should tell you that all the views that actually pull any data from ITF are read-only so I probably should just create cursors instead for those???"

Yes, a perfectly valid approach. OTOH thinking in the future you might be changing backends a view might be better (but then again you could get remote data into cursor too - if you're more comfortable with cursors then go with them IMHO).


"All the views that are used to update ITF, have a where clause that ensures they will be empty. In other words, I am only using them to ADD records to ITF.

2nd, Then there is all the stuff I have been reading about remote vs. local and ODBC and CONNECTION etc. I am pretty confused that what I am doing may not work.

There can be multiple users accessing accounts (and thereby effecting balances) from the ITF app.

There will be multiple POS apps (remember each POS app runs on it's own PC with it's own local data), but uses a wireless network to get to the ITF database."

If you're using only to ADD a view might be a killer rather than helper if not used correctly. IOW I think you're somewhat replacing 'insert-SQL' command with a view (unnecessary IMHO).

Remote and Local are really confusing at first, right. What's remote and how far remote it should be :) To make it easy you might change the remote/local words with nonVFP/VFPnative tables. A native DBF, directly sitting at your current directory, is obviously a local but it could be remote too - consider myTable.dbf :

create SQL view myView ;
  as ;
  Select * from myTable

This one is local view. Tells that myTable is a native VFP table.

Create connection "myConnection" ;
  ConnString "DSN=Visual FoxPro Database;"+;
  "UID=;PWD=;SourceDB=c:\myPath\ITF.dbc;"+;
  "SourceType=DBC;Exclusive=No;BackgroundFetch=Yes;Collate=MACHINE;"

*Now Create the view - this time remote
Create SQL view "myView" ;
   Remote ;
   Connect "myConnection" ;
   as ;
   Select * from myTable

You see the difference. Tells VFP should use an ODBC connection to source (it doesn't explicitly specify ODBC anywhere but remote views and SPT (SQL Pass Through) only use ODBC. There are also differences in operation between the 2 views but the main idea is there could be only one view type as 'Remote'.
Note: Remote views are meant to access < bg > to other type of databases like SQL server, Oracle, Access etc. Here I only showed a local (one using native VFP tables) could also be defined as a 'remote' view (and in cases preferable over local).

As you see a Remote view needs a Connection definition.
For a native DBF it'd mean simply 'the path to DBF'. Note that in 'Local' view definition we didn't specify a path at all (we might - but who hardcodes). An SQL would run and all it needs is to find myTable.dbf in search path.

If you look into SPT, it's more closer to your cursors only approach (if you'd need to behave as a REMOTE view). SPT, just like cursors, doesn't need a definition to be kept in DBC. Here's SPT version of our remote connection :

connHandle = SQLStringConnect( ;
"DSN=Visual FoxPro Database;"+;
  "UID=;PWD=;SourceDB=c:\myPath\ITF.dbc;"+;
  "SourceType=DBC;Exclusive=No;BackgroundFetch=Yes;Collate=MACHINE;" )

*SQLExec( m.connHandle, "An SQL command here", "IntoCursorNameIfACommandReturningRows" )
SQLExec(m.connHandle, "select * from myTable", "myCursor")
SQLDisconnect( m.connHandle )

Multiple users and multiple apps accessing a central database are a piece of cake for VFP :)

Well to summarize it sounds like you don't need views or SPT, at least today, and simple SQL cursors would work for you.

However if you have time (create time I suggest) and check views in more depth you might also find 'Offline' views as a valuable interface (not to confuse you, I feel they're used seldomly by VFP developers but whenever I see something like mobile with the possibilty of being disconnected that comes to mind).

Cetin