Joseph,

This sounds like a rights issue. Are you positive your test machines are set up to access your remote data? Do they have the correct network/sql server rights?

If you have VFP loaded on those test machines, I would suggest pasting the remote MetaDBC entry into your command window and trying to OPEN DATABASE.

---J

>My answers are in ***. Thanks again, Jason.
>
>
>Joseph,
>
>Just to make sure we're on the same page, are you saying:
>
>1. you have, by default, set up your environments to use local data, and then switched the remote view DEs?
>
>
>*** DEs are local, data business objects are remote. This combination works on the development machines but not the test machines. ***
>
>
>2. on your pc, leaving the default as "Use Local Data" causes no problem?
>
>*** Correct. ***
>
>3. on other machines, no matter what setting you use, something crashes. Both "Use Local Data" and "Use Default" crashes when using the first remote view, while "Use Remote" crashes when accessing the first framework local view?
>
>
>*** Correct. ***
>
>Also, are these other machines development ones or do they merely run compiled versions of your app?
>
>
>*** They merely run compiled EXE versions of my app from Windows Explore. ***
>
>(In the meantime, check all machines to be sure that the application registry settings -- and MetaDBC -- match what's on your pc)
>
>
>*** I'll need to take a closer look at the registry settings. I customized metadbcs for two test machines---one runs on the network, and specifies the same network path and DBC name for both the local and remote fields; the other runs on a laptop, and has "DATA\dbcname" in both the local and remote fields. ***
>
>---J