connecting to correct DBC 1

[huntert]

I have a program I run on a laptop and I have another copy on the server. When I return from roaming I upload the new records from the laptop to the server copy's DBC. This all works very well except when the program is run thru the EXE form rather than the project environment. I assume with the exe is built, it attaches the DBC to it. I close database all and reopen DBC on the server even though I am running the exe on my laptop. The server DBC is opened but it appears to use the local DBC files. It does not do this and works perfectly when the program is run from the project stage. Any help around this and why is this happening? Thanks so much. hunter

 

[craigsboyd]

I've noticed this too, I routinely end up with multiple copies of the data directory for an application and have seen where I can set the DBC in my application, but it still gets the data from the tables in the DBC that was part of my project when I last compiled it. Definately a VFP bug of sorts if you ask me. What I do, and this may or may not work in your case is hide the folder containing the DBC and tables that were in the project by renaming the folder before I run the exe. Other way to do this is to remove the dbc from the project before building the exe.

http://www.sweetpotatosoftware.com

 

[huntert]

Thanks Craig for the recs. I tried to remove the DBC from the project and then built the EXE but it did the same thing. I have to have the folder in that file because endusers may switch back and forth between sever and local. Any other thoughts? thanks hunter

 

[craigsboyd]

OK, well let's say you built the application with your dbc and tables in folder "C:\MyProg\MyBuildData\", but on the users' machines and server you made two copies of that MyBuildData... C:\MyProg\MyData and S:\MyData. This would effectively make it impossible for either dataset to see the other (assuming you are explicitly openeing the databases and setting them in your application). Now, where you would run into a problem is if one of your users grabbed a copy of the server data and just copied it down to their harddrive into the MyData folder... as the DBC may still hold references back to the tables in the S:\ drive. In this latter case you may have to write a routine to hack the dbc or backlinks in the tables to rectify this situation. It seems much easier to have them always use a copy of the data from your original MyBuildData folder. This all assumes of course that the users' machines cannot see the C:\MyProg\MyBuildData\ directory that you originally used to build the application.

http://www.sweetpotatosoftware.com

 

[huntert]

1)Would it be possible to hack the DBC file paths to change just the data folder file path to the server location and would this work? How do I get into hacking this info?

2)Where is the location to change the AutoOpenTable option and would changing this to .F. avoid the EXE opening the DBC table in the local DB and allow directing to the server data folder?

thanks once again and I really do appreciate the help... hunter

 

[darrellblackhawk]

This is some really squirrely code I wrote to allow me to select a test database if a value is set.

The project is built with the tables in the dataenvironment which are part of a DBC on a server.

As stated, if a value is set true, the DBC is closed and each cursor in the DBC is pointed to a different DBC.

Sorry for the jumble; I don't have time to edit and describe what it's doing, but it works.

Procedure UseTestData(loFormOrDE,bDontClose)
  If gbUseTestDataSet
    If !bDontClose
      loFormOrDE.DATAENVIRONMENT.CLOSETABLES()
    Endif
    Local i, lcMac, lbPartOfDBC
    i = 0
    Do WHILE .T.
      i = i + 1
      If !bDontClose
        If PEMSTATUS(loFormOrDE.DATAENVIRONMENT,"Cursor"+TRANSFORM(i),5)
          lbPartOfDBC = !EMPTY(EVAL("loFormOrDE.DATAENVIRONMENT."+"Cursor"+TRANSFORM(i)+".database"))
          If lbPartOfDBC
            lcMac = "loFormOrDE.DATAENVIRONMENT."+"Cursor"+TRANSFORM(i)+".database='\\Absserv\Company\CollectionsTestData\collections.dbc'"
            &lcMac
          Endif
        Else
          Exit
        Endif
      Else
        If PEMSTATUS(loFormOrDE,"Cursor"+TRANSFORM(i),5)
          lbPartOfDBC = !EMPTY(EVAL("loFormOrDE."+"Cursor"+TRANSFORM(i)+".database"))
          If lbPartOfDBC
            lcMac = "loFormOrDE."+"Cursor"+TRANSFORM(i)+".database='\\Absserv\Company\CollectionsTestData\collections.dbc'"
            &lcMac
          Endif
        Else
          Exit
        Endif

      Endif
    Enddo
    If !bDontClose
      loFormOrDE.DATAENVIRONMENT.OPENTABLES()
    Endif
    If USED("acc_coll")
      Go TOP IN "acc_coll"
    Endif
  Endif

Endproc

 

[darrellblackhawk]

Paired down the code snippet I supplied earlier.
A little description...

Procedure ChangeDBC(oFormOrDE,cDBC)

  * Close tables in DE
  oFormOrDE.DATAENVIRONMENT.CLOSETABLES()

  Local i, cMac, bPartOfDBC

  i = 0

  Do WHILE .T. && Loop until we don't have anymore cursors in DE
    i = i + 1

    * Does the DE contain this cursor? i.e. Cursor1, Cursor2, etc.
    If PEMSTATUS(oFormOrDE.DATAENVIRONMENT,"Cursor"+TRANSFORM(i),5)

      * Flag if the cursor is part of a DBC
      bPartOfDBC = !EMPTY(EVAL("oFormOrDE.DATAENVIRONMENT."+"Cursor"+TRANSFORM(i)+".database"))
      

      * If it is, change the DBC pointer in the cursor via macro substitution to cDBC
      If bPartOfDBC
        
        cMac = "oFormOrDE.DATAENVIRONMENT."+"Cursor"+TRANSFORM(i)+".database='"+cDBC+"'"
        &cMac

      Endif

    Else

      Exit && No more cursors in the DE...

    Endif

  Enddo

  * Reopen the cursors
  oFormOrDE.DATAENVIRONMENT.OPENTABLES()


Endproc

 

[huntert]

Thanks alot for the code. The code itself looks good and I appreciate it. I do have a few questions related to its use. The two parameters used are 'oFormOrDE,cDBC'. The cDBC seems pretty striaght forward as the database container file path and name. The oFormOrDE is the database envornment object name I assume. How do you get this handle/name? Also is this object at the form level and needs to be call for every form (if so in init? or...) or is this at the DBC level and is used once to clear out the wrong cursors when the DBC is changed? Thanks so much. hunter

 

[darrellblackhawk]

oFormOrDE is either a form that has a ref to a DataEnvironment or a DataEnvironment that's constructed.

The method ChangeDBC() is called after the form or dataenvironment has been initialized with a ref to the form or DE in question - and of course the path to DBC.

I'm glad it helped. I use it all the time to test applications.

Darrell

 

[huntert]

STill can't get this one?

I have tried to use the form name "Clinical" to replace the OFormOrDE variable name and I have tried to use "thisform". I get an error stating this does not refer to anything. I thought when the form was created by the exe or developer run time, the dataenvironment name would be the same as the form's name. What am I missing? I am putting my call to this procedure first in the INIT method so when the data is called it uses the correct dataenvironment. I have SQL calls in the method also but I assume this will correctly point to the correct database after the cursor rewrite. thanks once again. hunter.

 

[darrellblackhawk]

Sorry for taking so long to get back to this.

The code snippet assumes you've use the IDE to create a form.

The token DATAENVIRONMENT in oFormOrDE.DATAENVIRONMENT...,
refers to the default name vfp assigns to the dataenvironment
object the vfp creates in a form.

Unless you change it; which I don't believe you can when
its created using the form designer, it should work as
coded.

Post the code you've created so I can review it.

Darrell

 

[Olaf Doschke]

The whole thing may really be an issue of compilation. How paths are interpreted within an exe strongly depends on where it is compiled. Especially look at the last two posts in this thread: thread1252-1003840

Bye, Olaf.