Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

dumb question (perhaps) about copying database files

Status
Not open for further replies.

joebloeonthego

Technical User
Mar 7, 2003
212
CA
can i safely copy live db files so that I can work with them outside of foxpro? I've assumed it's fine, as I've been doing it without any apparent problems, but I don't know if the file was ever actually 'in use' when i was copying it. I want to write a batch/macro that copies a few db files out and imports them into access, but I don't want to start if it will screw things up.
thanx!
 
You can copy them with a couple caveats. If they are attached to a database (dbc) you can't copy them. They need to be free tables. If you use free tables, however, you are limited to 10 characters for field names. The better solution would be to do SQL calls to copy the data, e.g., SELECT * FROM
INTO CURSOR [CursorName] READWRITE. This will retain your long field names and allow you to work with the data in the cursor.
 
they're all .dbf, .cdx, and .fpt files. I don't think any of the fieldnames are over 10 chars. Do you mean run the select statement from foxpro? because that won't be possible as it's a program based on foxpro, and the user will be probably working from access when running the reports (for example).
(We need some really specialized reports that won't be possible to get from the foxpro-based program - so I was thinking of copying them with a batch file or something and then importing them to access to run the reports)
 
It sounds like the tables are not in a database so you should be able to just copy them. You could also set up ODBC access to the tables from Access. If they hqave access to the original tables, an ODBC connection would eliminate the need to create separate copies of the Fox Tables. The bigger question is why anyone would want to use Access for anything. ;)
 
I thought about odbc but was worried about file-locking issues and stuff. If that's not a problem with odbc, I would probably just do that.
oh, and Access because we need to do a bunch of reports involving several tables and access seems to be the quickest/easiest/most comfortable thing around here. I always just use the report wizard. *ducks* I guess I could use foxpro too, but I would still have the same issues with the db files, no? (I have no idea how the file-locking and stuff is done with foxpro, so I assume two instances wouldn't know what the other is doing - I of course could be (and probably am) wrong.)
thanx for all the help.
 
joebloeonthego,

Be aware that if you attempt to copy files while they are open in an application, you will get a file-sharing violation. That is nothing to do with VFP -- it is normal Windows behaviour.

Mike


Mike Lewis
Edinburgh, Scotland
 
Us Fox Guys can be a little sensitive :). If youre using ODBC you won't have any problems with file locking IF the tables are not being used exclusively. IF they are, you will have some file locking issues.
To handle locking issues inside of Fox, you set up buffering as appropriate. Most people use optimistic table buffering, but it depends on your needs and situation. You do need to make sure you do Tableupdate() as appropriate. By the way, if youre using Visual FoxPro 8, you can handle all kinds of data (ODBC, XML, SQL, Native) within your forms and data environment. I would definitely look into it for your future work.
Reports in Access do have the advantage of being published directly to Word which Fox has to do by calling the object and playing with it. (Hear that M$!!)[bigears]. I guess they figure us Fox guys can do anything.
 
I would expect that, but I've never had that problem, even when I couldn't open it up with foxpro (file is locked) windows still let me copy it off the server to my desktop. That's why I'm wondering about the safety of doing such a thing. It's just copying, so it _should_ be fine, right? right? :)
 
Yes, it's a windows file copy. BUT, if you are copying at the same moment someone is copying back to the table, it could corrupt the table. The same moment thing could get you.
 
The problem is that I'm using a proprietary foxpro application, one I have no control over, so I'm trying to use the files without screwing up anything (of which I don't really know what they're doing)
 
oooh.. so using a windows/DOS copy on a live table _could_ have consequences. Thanx, that's the answer I was looking for. Now, with that option gone, would you know whether an access direct link (link table) or odbc connection be any safer? (I tried a quick direct link to a table in our test database, and I couldn't do anything because the table was locked - so I assume it is safe, but at the same time not very helpful as the table will probably be locked most of the time and therefore not really accessable.)
I guess I could just copy them at night or something, I'm sure having the data updated once a day would be good enough.

*** Did you mean the copied table could be corrupt or the original table? (I assumed you meant the original table)

thanx for all the help!
 
Without rewriting the Fox App, you can't be sure you won't hit at the same moment. The ideal would be to add a copy function to your Fox App (which it sounds like you can't do)The other thing you could do is write a small Fox App that uses the data SHARED and does the copy or do a SQL to cursor. Then, if it's in use EXCLUSIVE you'll get an error that you can trap.

 
Copying at the same moment could corrupt both the copied AND the original tables. Fox tables are notoriously sensitive.
 
yikes! I'll stop doing it then. :)
It looks like for safety's sake, I'll just copy them at night, as there seems to always be someone in the module that locks the tables you want to get at, so linking is probably not going to work.
Thank-you very much for all the advice.
 
No problem. I would definitely try the small Fox App concept. You can write an error trap if the table's in use, so you wouldn't have the copy issue. Good luck
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top