At 12:46 PM 10/3/2007 +0100, Paul Newton wrote:
...
>In my code I am creating a temporary DBC, and subsequently adding and
>dropping tables. I am ensuring that none of the tables belonging to
>Temp.DBC are open when I am through. Now I want to ERASE the Temp.DBC
>(etc) files from disk and cannot do so because I cannot find a way to
>close Temp.DBC
>
>Any suggestions ?
>
>Also how can I save (and restore) the current database setting (before
>and after my code)
Sorry this is a response (ong-winded) to an old question. I think the
response may address another question someone else had regarding same-named
DBC's.
Anyway, the short of it is that you can uniquely reference a specific
database by prefixing the path location. For example:
cDB1 = "g:\production\important\financial.dbc"
cDB2 = "c:\temp\blah\blah\financial.dbc"
- Note that the name of the DB is "financial"
- So you could do something like
OPEN DATABASE (cDB1)
OPEN DATABASE (cDB2)
- At this point, the cDB2 is the 'active' DB - think of it as a sort of
'current work area' that we have with DBFs. If you open tables right now,
you'd be opening them from the dbc that is located in c:\temp\blah\blah\
To close a specific database you "SET" (or OPEN) the DB and then issue a
close DB. For example
OPEN DATABASE (cDB1)
OPEN DATABASE (cDB2)
... various code done here...
SET DATABASE TO (cDB1)
CLOSE DATABASE
- At this point, the DB from g:\production\important\ will be closed. And
any opened tables belonging to that DB will be closed as well. The DB in
c:\temp\blah\blah\ is still open, and any tables opened from that database
are still open.
- By the way, it appears that the OPEN DATABASE command will work just as
well regarding setting the "current" database. In fact, it may be safer to
use - if you issue a SET DATABASE TO ... command to a database that is not
open, you'll get an error (which you could trap in a TRY...CATCH..., etc,
or you use a DBUSED() call, using the full path name before issuing the SET
DATABASE command, etc.). Also, the ADATABASES() function comes in handy here.
- So, to close down a temporary DBC, keep track of your it's location (and
name of course) and then do the SET DATABASE (or OPEN DATABASE), and then
follow it immediately with a CLOSE DATABASE command.
Ah, now I remember. Someone was asking how to copy tables from 1 DATABASE
to another DATABASE of the same name. Here is some code (not tested, and
with no error trapping). Note, the code below will probably work as far
base as VFP 6. But I'd recommend putting in TRY...CATCH... where
appropriate and VFP 8 is where those were added.
*-- General process: open source database, create target database,
*-- step through tables in source DB and copy to target DB, preserving
*-- table indexes, etc
m.cSourceDB = "x:\proddata\systemA\famis.dbc"
m.cTargetDB = "c:\temp\famis.dbc"
m.cTargetPath = ADDBS(JUSTPATH(cTargetDB))
CREATE DATABASE (m.cTargetDB)
OPEN DATABASE (m.cSourceDB)
*-- Note: the cSourceDB was just opened, so "USE"ing tables will come from
there
m.nTbls = ADBOBJECTS(_aTbls, "TABLE")
FOR m.nCount = 1 TO m.nTbls
m.cTblName = _aTbls[m.nCount]
USE (m.cTblName) IN 0 ALIAS WORKING
SELECT WORKING
COPY TO (m.cTargetPath + m.cTblName) ;
DATABASE (m.cTargetDB) ;
NAME (m.cTblName) WITH CDX
USE IN WORKING
ENDFOR
OPEN DATABASE (m.cTargetDB)
CLOSE DATABASE
OPEN DATABASE (m.cSourceDB)
Note that the above doesn't copy stored procedures, triggers, etc. That is
also possible (by opening the DBC as a table and copying the correct
records over), but I won't go into that at this point. Also, the above
assumes the filename of the tables are the same as the table names stored
in the DB. If that is not desired, then you'd have to use the "DBF()"
command and add a few more lines of code. Also, some of my conventions may
not really be needed. I generally always do a USE .... IN 0 so as to not
step on any currently open tables. But if you use private datasessions,
then you probably won't need that clause and the subsequent "SELECT
WORKING" command.
Note that during the copy process you can filter out whatever
records/tables you would not want to go into the new DB (various clauses of
the COPY TO... and checking table names as they're being stepped through).
I've done this quite often for cases where 'publicly available' data was to
be a subset of data actually available.
HTH
-Charlie
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
