Move a folder and its contents 3

[jimstarr]

I have an application wherein the data tables reside in a sub-folder called "Data". The customer would like a feature added to allow the user to move this sub-folder and its contents (they're all DBF's and CDX's) to an unspecified location of his choice at runtime.

Other requirements:

1. The new folder is also called "Data"

2. The tables are already open. They must remain open and their movement should be transparent to the rest of the app.

3. In subsequent runs the app must remember where the tables have been moved to.

4. The original Data folder must be erased.

What's a good, clean way to get this done? Thanks!!


Jim

 

[Olaf Doschke]

You can use COPY FILE or RENAME TABLE, if condition 2 would not need to be true. I wonder why tables must stay open? You can't move a file, that foxpro has open, you can copy it, but you can't move it, and changes on the open tables will then be made to the old directory. Therefore close all data, then move the files, that's possible.

Bye, Olaf.

 

[SnyAc]

Yep... no way to move the tables while they're open... just not possible.

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[jimstarr]

You're right - the tables don't need to remain open. They just need to be open and accessible after the operation.

What about condition 3?

 

[Mike Lewis]

Jim,

The easiest way to move a bunch of files is with the RENAME command. For example:

RENAME c:\Source\*.DBF TO c:\Target\*.DBF

will move all the DBFs from Source to Target. (The target directory must already exist; if it doesn't, use MKDIR to create it.)

As for point 3, there are many possibilities. You could use an INI file to store the new directory path; or you could put it in the registry; or you could use a small table in the application's root directory.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[alvechurchdata]

Mike's solution is fine if you're on a single-user database (although it perhaps should be *.* rather than *.dbf) but you'll have to put some protection around it for any multi-user system.

You'll certainly have to force all the other users to log off before you start the process but you'll also have to prevent any of them logging back in before the process has finished. If someone manages to USE a table before the RENAME process reaches that table then it'll crash (I think) and you'll be left with half the tables in each folder.

You'll also have to look for something more complex if you've got a database container because the dbc will still think that its tables are in the old folder.



Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Olaf Doschke]

The only thing seemingly hard to do with point 3 (configuration of the database path), is, that dataenvironments of forms don't change within an exe, if you move the data. But for the dataenvironemnts it will be sufficient, if it finds the table somewhere in a path setup with SET PATH.

So the only difficulty is storing a new path, that itself is easy, use a DBF or INI file or whatever. You could also store it in the registry. It just needs to be in some place your app will find it at start, that does not change. An INI or DBF within eg the "Program Files" folder has the difficulty to be readonly by default, but you can set access rights to such configuration files within the setup you create, that does not need to stay at the default.

In general it's good to have one starting point as registry, ini or whatever you like, containing configuration or even more flexible the paths/connections to further local and central configurations.

Bye, Olaf.

 

[jimstarr]

Thanks, guys. Am using RENAME and a small dbf in the root directory.

Jim

 

[markros]

Check Copy, Move, Rename File Preserving Destination Name Case and

File operations with Progressbar