Local View vs Remote View

Local View vs Remote View

Post by UGV0ZX » Thu, 29 Dec 2005 10:22:02


I want to know the pros and cons using local views vs using remote views to
access Foxpro tables.

For a local view, the Advanced Options in the View Designer is disabled.
Does it mean that all the settings in the Advanced Options are not available
for local views?


Thanks for any help.
 
 
 

Local View vs Remote View

Post by Cindy Wine » Thu, 29 Dec 2005 10:38:13

Hi Peter,

Which version of FoxPro are you using? What are the "Advanced Options" you
are referring to? In VFP9 the View Designer is exactly the same for remote
views as it is for local views, excepting the necessity of having an
associated connection.

Are you perhaps referring to the settings on the Tools > Options > Remote
Data dialog?

In order to make any sort of decision about views you need to identify why
you want to use views rather than using Fox tables natively. Also, have you
considered using CursorAdapters?

--
Cindy Winegarden MSCD, Microsoft Visual FoxPro MVP
XXXX@XXXXX.COM www.cindywinegarden.com

 
 
 

Local View vs Remote View

Post by Paul Peder » Thu, 29 Dec 2005 21:08:29

It sounds like you might be a bit confused. A "local" view is a view based
on FoxPro tables; a "remote" view is based on another back end, such as
MSSQL, Oracle, My SQL, etc. You do not have a choice of using local views
vs. remote views. If you use a view on FoxPro tables, it will be a local
view, by definition. If you use a view based on non-FP-native data, it will
be a remote view.

If you're looking at FoxPro tables, you do have a choice whether to use
(local) views or to access the tables directly. When dealing with non-native
data, you may have a choice of using (remote) views, or some other method.
 
 
 

Local View vs Remote View

Post by Dan Freema » Fri, 30 Dec 2005 01:47:15

You certainly can create remove views of VFP dbf's! Just create an ODBC DSN
pointing to your VFP tables and go at it.

There is seldom any good reason to do this, unless you want to design your
app to always use views and only need to switch the connection to a back end
once you've designed & written the app. (NOT the best way to go, but
doable.)

Dan
 
 
 

Local View vs Remote View

Post by Paul Peder » Fri, 30 Dec 2005 04:15:44

Yes, that's correct.

I wonder why I didn't think of it? ;-)
 
 
 

Local View vs Remote View

Post by UGV0ZX » Fri, 30 Dec 2005 04:32:04

Hi Cindy, Paul and Dan,

Thanks for your reply.

I'm using VFP9 SP1.

The Advanced Options I'm referring to is the menu selection under Query
menu. It is disabled if I'm working on a local view.

I'm trying to create forms which will handle both VFP data and SQL Server
data. I will have the following scenarios for a scx:

1. All the data will be from SQL Server only. For example, table1, table2,
and table3 are all SQL Server tables and they will be accessed using ODBC
remote views.
2. Some data will be from SQL Server and some from VFP. For example,
table1 and table2 are SQL Server tables and table3 is VFP table and they will
be accessed using ODBC remote views. Table1 and table2 have structures
corresponding to their VFP counterparts in scenario #1.

I have 2 applications app1 and app2 which are almost identical in
functionalities except one is using VFP tables and the other one is using SQL
Server tables. Now, I'm taking an identical part out of both applications
and making it as a third application app3.
1. When app3 is called by app1, app3 will only use SQL Server tables.
2. When app3 is called by app2, app3 will use both SQL Server tables and VFP
tables. The VFP tables used in this case are counterparts of the ones used
in case #1.

Thans for any help.
 
 
 

Local View vs Remote View

Post by UGV0ZX » Fri, 30 Dec 2005 04:38:05

This is to correct a mistake in my last reply.

The paragraph

2. Some data will be from SQL Server and some from VFP. For example,
table1 and table2 are SQL Server tables and table3 is VFP table and they will
be accessed using ODBC remote views. Table1 and table2 have structures
corresponding to their VFP counterparts in scenario #1.

should be

2. Some data will be from SQL Server and some from VFP. For example,
table1 and table2 are SQL Server tables and table3 is VFP table and they will
be accessed using ODBC remote views. Table3 have structures
corresponding to its SQL Server counterparts in scenario #1.


Peter
 
 
 

Local View vs Remote View

Post by Craig Bern » Sat, 31 Dec 2005 01:25:38

You don't need to do it that way. You can use both local and remote, then
switch the data source by changing the OpenViews property of the
DataEnvironment.

--
Craig Berntson
MCSD, Visual FoxPro MVP
www.craigberntson.com
Salt Lake City Fox User Group
www.slcfox.org
www.foxcentral.net
 
 
 

Local View vs Remote View

Post by UGV0ZX » Sat, 31 Dec 2005 04:48:05

i Craig,

Thanks for the reply. However, I don't quite understand how OpenViews will
help in my case. As of now, I'm thinking to resolve my issue is to change
the database property of a view to either the database containing the remote
view for SQL Server tables or the one containing the remote view for VFP
tables.

I'm trying to create forms which will handle both VFP data and SQL Server
data. I will have the following scenarios for a scx:

1. All the data will be from SQL Server only. For example, table1, table2,
and table3 are all SQL Server tables and they will be accessed using ODBC
remote views.
2. Some data will be from SQL Server and some from VFP. For example,
table1 and table2 are SQL Server tables and table3 is VFP table and they will
be accessed using ODBC remote views. Table3 have structures
corresponding to its SQL Server counterparts in scenario #1.

I have 2 applications app1 and app2 which are almost identical in
functionalities except one is using VFP tables and the other one is using SQL
Server tables. Now, I'm taking an identical part out of both applications
and making it as a third application app3.
1. When app3 is called by app1, app3 will only use SQL Server tables.
2. When app3 is called by app2, app3 will use both SQL Server tables and VFP
tables. The VFP tables used in this case are counterparts of the ones used
in case #1.


Peter


"Craig Berntson" wrote: