Set database to mydatabase Close data Set database to myotherdatabase JH
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Coleman Sent: Tuesday, October 09, 2007 9:37 AM To: ProFox Email List Subject: Re: Erasing a temporary DBC 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 [excessive quoting removed by server] _______________________________________________ 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]@shelbynet.com ** 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.
