Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Using local DBC not Network DBC
Message
From
22/11/2001 09:36:15
 
 
To
29/08/2001 00:43:36
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00549515
Message ID:
00584904
Views:
45
Dragan do you have your production copy of this code at hand

It looks like it would be much simpler to use than what I am doing at present.

Many Thanks
* app.CheckDataEnv
lParam oDE
=amembers(aCurs, oDe,2)
for each cCursor in aCurs
  oCursor=eval(cCursor)
  if oCursor.baseclass='Cursor'
     if !empty(oCursor.database)
       oCursor.database=[ some stuff to put a proper path here]
     else   && a free table
       oCursor.cursorsource=[ proper path to the table ]
     endif
  endif
endfor
dodefault()
>>This problem just started on a few of our developer's PCs and we've been unable to track it down.
>>
>>I build and test an application on my hard drive (c:\) and everything is OK. I then copy the EXE to the Network to test with the live system.
>>PROBLEM: The DBC is referencing tables on my hard drive or it's using the DBC from my hard drive NOT the Network. If I rename the folder on my hard drive and rerun the EXE it works properly. We tried compiling the same code on another PC and it works OK.
>>
>>I've checked all my paths and I'm not referencing the hard drive anywhere!
>
>I've had this problem - we've been supplying some apps copied to a different directory on the same server, and the tables opened were actually the ones in development, not in the testing directory. It seems that though the paths in the form's cursor objects are relative, they get compiled into absolute paths somehow. I've tried searching for these absolute paths in the .objcode or elsewhere, to no avail. Still, once the mapping to the original development drive was removed, it started pointing at the right data. This doesn't hurt production tables, since the end user doesn't see the original tables, but did hurt testing (or was a major hassle, at least). The solution was to manipulate cursor objects in .dataenvironment.beforeopentables; pasting the code everywhere would be too much, so it came down to this:
>
>* code in de.BOT
>goApp.CheckDataEnv(this)
>
>i.e. I was calling a method in the app object, passing the DE as a parameter. The code there is not at hand (I'm home now), but synopsis would look like this:
>
>
* app.CheckDataEnv
>lParam oDE
>=amembers(aCurs, oDe,2)
>for each cCursor in aCurs
>  oCursor=eval(cCursor)
>  if oCursor.baseclass='Cursor'
>     if !empty(oCursor.database)
>       oCursor.database=[ some stuff to put a proper path here]
>     else   && a free table
>       oCursor.cursorsource=[ proper path to the table ]
>     endif
>  endif
>endfor
>dodefault()
>
>You'll need full paths at this point, that's what it's expecting. In my case, I was looking for pieces of paths, and replaced with forcepath(.database, [new path]), where New Path would be one of the four possible directories I was using, depending on which piece of the original development path I found. YMMV, of course, but once you get it to store proper paths, it works and you can forget about it.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform