How to redirect the data environment

[Jim Walsh]

I am debugging a VFP 7 SP1 application (an EXE). The application runs a
form. While developing this application, I have been working with a dummy
version of the database (DBC and associated data, index, etc files) that is
on my development computer.

When I run the EXE, I can direct the data environment of the enclosed forms
using the DEFAULT = statement in the CONFIG.FPW file in the folder
containing the EXE. In this way, I can run the EXE against either my dummy
data, or any other copy of the database my test users are working with on
their computers.

I've run across a bug in the EXE that I am having trouble isolating. If I
run the EXE against the database on another computer, I get the error. When
I set DEFAULT = to the folder containing the database on my development
computer, I don't see the problem.

So, I'm trying to debug this code using the VFP debugger. I have set the
Tools...Options...File locations...Default Directory and Search path to
point to the other computer. However, when the form in my application runs,
it always works with the database on my development computer.

I have built this application using the VFP application wizard. So, the
shell program (PRG) is derived from app_application in _framewk.vcx.

Does anyone know how the location of the database that is used by a form is
determined? Or, for that matter, at what point does the database get opened.

Thanks for your help.

Jim

[Dan Freeman]

What error message are you getting?

[Jim Walsh]

Dan,

Thanks for responding to my query. There are really two aspects to this. The
first is the actual error that I'm seeing, and the second is my inability to
reproduce the problem from within the debugger as a result of not being able
to redirect the data environment to use the database as it is stored on
another computer. So, please don't lose sight of the question I actually
asked.

1. The error that I am getting is Error #1. The text line is something like
"Unable to access file <so and so>", where the <so and so> appears to be an
incomplete path to a file in the VFP program folders. Forgive me, since I
don't currently have access to that development machine, but the <so and so>
was something like "C:\Program Files\Microsoft Visual FoxPro 7\model". I
have no idea what part of my program (or the application framework) might be
attempting to access this.

2. The error is occurring sometime after I have successfully logged in,
using that feature of the VFP application framework. So, it is accessing my
user table which happens to be in the same folder as the database itself.
So, I don't believe the problem is user access to the folder containing the
database.

When I run the same application from within the VFP debugger, I don't get
the error, but also when the first form comes up, I realize that it is
accessing the database on the development system itself. I am trying to
tease that discrepancy out of the mix in order to isolate the source of my
problem. Thus, the motivation for my posted question.

Thanks again Dan.

Jim

"Dan Freeman" <d...@dfapam.com> wrote in message
news:uqXrqgL9...@TK2MSFTNGP11.phx.gbl...

[Lee Mitchell]

Hi Jim:

Take a look at these articles and see if they shed any light on this
problem:

128996 HOWTO: Assign Database Location Generically in Data Env
http://support.microsoft.com/?id=128996

147941 How to Handle Path Issues When Moving Databases
http://support.microsoft.com/?id=147941

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

[Mark Stanton]

In article <OlcgqBL9...@TK2MSFTNGP10.phx.gbl>, Jim Walsh wrote:

> Does anyone know how the location of the database that is used by a form is
> determined? Or, for that matter, at what point does the database get opened.

Yes, the full path of the database is in the dataenvironment. Are you sure
you're able to switch database in your development environment the way you
describe? It doesn't sound like it's working.

What you need to do is fiddle with the value of
ThisForm.DataEnvironment.<EachCursor>.Database
in the "BeforeOpenTables" method of the dataenvironment.

Regards
Mark
-If more of us acted more sensibly,
d'you think Governments might join in?

[Jim Walsh]

Lee,

Thanks for your help. Let me ask a couple of questions related to this.

This is my understanding:

The data environment is part of my form. So, when the form opens, it has no
problem finding its data environment. The data environment contains one
cursor object for each table that was "added" to the data environment. Each
cursor contains a database property that contains the full path to the
database container (DBC file) that contains information about the table that
the cursor is using. The DBC file in turn contains a relative path (relative
to itself) to each of the tables in the container. When my form opens, and
opens the data environment, an attempt is made to open the tables associated
with each of the cursors. If the DBC file can not be found using the path
contained in the cursor's database property, then a search is made for the
DBC.

The questions I have concern where VFP searches for the DBC in this case.
For an executable applications containing a form, what role does the DEFAULT
= statement in CONFIG.FPW play? If the form is run from within the VFP
development environment, what roles do the settings in
Tools...Options...File locations (Default Directory and Search Path) play?

Jim

"Lee Mitchell" <Le...@microsoft.com> wrote in message
news:VA$fGuU9C...@cpmsftngxa08.phx.gbl...

[Miroslav Gjurinski]

In config.fpw put this (for example):

SCREEN = OFF
DEFAULT=d:\DIR2\
PATH=C:\DIR1\DATA\, d:\DIR2\, d:\DIR2\DATA\, d:\DIR2\DATA\LOKALNO\02\
TMPFILES=d:\TEMP\02\
EDITWORK=d:\TEMP\02\
SORTWORK=d:\TEMP\02\
PROGWORK=d:\TEMP\02\
COMMAND=DO 'd:\DIR2\main.app'

config.fpw should be in the same directory as the main app

If your 'dummy' database is located in C:\DIR1- remove it from there

If database is not in 'design' directory it shall be searched through
PATH=...

It works for me.

By,
Miroslav

[Jim Walsh]

Miroslav,

Thanks for your help. I think I'm starting to catch on.

One thing that has been confusing is that running an application within the
VFP debugger seems to behave differently than running a stand alone VFP app.
I believe that the rules that you outlined still apply, but within the
development environment, the Default directory, and Search path are taken
from Tools...Options...File locations. Is that your understanding too?

Jim

"Miroslav Gjurinski" <miroslav....@ka.hinet.hr> wrote in message
news:b6e3n1$5sf4$1...@as201.hinet.hr...

[Lee Mitchell]

Hi Jim:

I am glad this thread is helping improve your understand. This is
peer-to-peer support at it best!

Yes, when you run in the IDE, then the Tools>Options> File Locations>
Search Path option does effect where VFP looks for files. I believe that
the SET PATH also comes into play here, too.

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

>Miroslav,

[Jim Walsh]

Lee,

Thanks for following this thread. I was wondering if you could comment on my
posting of yesterday, about the roles that Default directory and Search path
play in finding the database container, associated tables, and other
resources used by forms.

My postings of recent days really are motivated by the problem I'm having
that is described in the other posting I made today about a possible bug in
the application framework. All of the posting of previous days were
motivated by the odd error message that I get that it can't find a certain
file, and the path it prints is in the VFP program folder, subfolder
\model\. There is no such folder.

I get this message from my compiled EXE, but not when I run the application
from inside my debugger.

So, what's up??

Lee, when the problem that we're seeing arises from issues (bugs?) inside
the framework that comes with VFP, I think it is important that someone at
Microsoft respond to the issue. When I fail to see such a response, it
weakens my believe that Microsoft is really standing behind this product.

Jim

"Lee Mitchell" <Le...@microsoft.com> wrote in message

news:9mcbnGT#CHA....@cpmsftngxa06.phx.gbl...

[Miroslav Gjurinski]

In form data environment files are opened from location you choose when you
create a form and in
development environment you always must have files in this location. But
when you run the form if files are not there they
are searched through a PATH. PATH in config.fpw file you have in app
directory is taken - not in -> tools -> file
locations.
you should start your application vith something like this:

"C:\Program Files\Microsoft Visual FoxPro 7\vfp7.exe" "-Cc:\gp
com\config02.fpw"

You can create your fpw file (config02.fpw) and set as a parameter of
vfp7.exe

Problem is when you want to start application from one PC with development
database and from some
network location too. Than you have to rename your local development data
directory.

I hope it would help you. My english is not so good but I think you'll
understand me.

Miroslav

"Jim Walsh" <jwal...@OVEtuspm.temple.edu> wrote in message
news:#7Q1xvS#CHA...@TK2MSFTNGP12.phx.gbl...

[Igor Korolyov]

Hi, Jim!
You wrote on Wed, 2 Apr 2003 10:24:23 -0500:

JW> One thing that has been confusing is that running an application within
JW> the VFP debugger seems to behave differently than running a stand alone
JW> VFP app. I believe that the rules that you outlined still apply, but
JW> within the development environment, the Default directory, and Search
JW> path are taken from Tools...Options...File locations. Is that your
JW> understanding too?

It will be so, if you don't start VFP IDE from the folder, where this
config.fpw reside, otherwise config settings will override registry
settings, you usualy see in Tools\Options dialog.

Stop the war!

WBR, Igor

[Jim Walsh]

Hi Mark,

Have you been following this thread?

I've made a better understanding of this question since I first posted.
There have been some useful observations. This is presently my
understanding:

1. The cursors in the data environment of a form have a database property
that contains the full path address of the database container for the tables
that the cursors use.

2. The database container contains a relative path for each of the tables in
the database. This path is relative to the location of the container itself.

3. If the database container is physically located as described in those
properties, then that is what is used.

4. If the database container is not there, then VFP will search for it. I
believe that search uses the DEFAULT directory, and the PATH.

5. If it is then able to locate the database container, it will use the
relative paths listed in it to find the database tables.

6. So, it is possible to redirect the data environment of a VFP application
by (a) making sure that the database is NOT located in the folder identified
in the database properties of the environment's cursors, and (b) setting the
DEFAULT folder to the path to a database that the user wants to use.

I've been experimenting, and made an interesting discovery. When I redirect
the data environment as I've just mentioned, the database properties of the
data environment actually get changed to point to the new database
container. At least this is true when I run within the development
environment. In order to get the form to use its original database, I have
to make sure that it is not able to reach the database in its alternate
location. Very curious.

Jim

"Mark Stanton" <msta...@cix.compulink.co.uk> wrote in message
news:VA.000020f...@cix.compulink.co.uk...

[Andrew R]

We overcame this by putting a custom method in our Form baseclass,
UpdateDataLocation.

This method takes a DataEnvironment as a parameter.

If then amembers the DataEnvironment.

If members exist it goes through them looking for cursors.

if the cursor Database property is not empty its path is changed the one we
want (some property or variable somewhere).

If Database is emtpy it is a free table and the CursorSource is changed.

Now, the boring part.

In everyform you are using a DE for add

THISFORM.UpdateDataLocation( THIS)
RETURN DODEFAULT()

to the BeforeOpenTables Event.

Now you can change the pointer at will.

Andrew R.

"Jim Walsh" <jwal...@OVEtuspm.temple.edu> wrote in message

news:eLUZeif#CHA....@TK2MSFTNGP10.phx.gbl...

[Mark Stanton]

In article <b6hmia$5jel3$1...@ID-105978.news.dfncis.de>, Andrew R wrote:

> We overcame this by putting a custom method in our Form baseclass,
> UpdateDataLocation.

Which is more what I was suggesting. I prefer to tell the app exactly what I
want than stop it finding what I don't want and then expecting it to find the
right thing. Picky? Yeah, maybe.