How to copy cfg file from local folder to the main server without error File is in use? 3

[gryff15]

Upon login, I copy the CFG file from the main server at F: drive to my local C: drive.
Copy File "F:\sys\billing.cfg" To Sys(2003)+"\billing.cfg"
In my form, I use the cfg file for my grid table.
At Load event: USE SYS(2003)+'\billing.cfg' ALIAS bill Shared
Then I modify my data through the grid and when I close the form, I want to apply the changes to the main server too because every time I login, the changes will be overwritten.
I tried to put these codes on my Close button:
Copy File Sys(2003)+"\billing.cfg" to "F:\sys\billing.cfg"
but it says File is in use.
I tried the alias: Copy File bill to "F:\sys\billing.cfg"
Still with error: bill.cfg does not exist.
I don't know how to copy my changes from my local folder to the main server at F: drive.

- webrider -

 

[Olaf Doschke]

Your try to copy BILL as alias will fail, as it will not be taken as alias name, COPY FILE only has the file name clause and that will be DBF("Bill") and overall would need to be put into brackets as a name expression to not be taken literally. COPY TO would save the data into a new DBF file. You might move to that way of writing it back out, but why, if you already have the file. Besides, the differing CFG file extension also wouldn't be a reason it doesn't work.

When you already use the expression Sys(2003)+"\billing.cfg" I'd continue that, better use COPY FILE with both names put into outer brackets like this:

Copy File ("F:\sys\billing.cfg") To (Sys(2003)+"\billing.cfg")
*and
Copy File (Sys(2003)+"\billing.cfg") to ("F:\sys\billing.cfg")

And then I don't see how a table used shared will hinder you to copy it. Is it really the use of the local billing.cfg or the use of the server cfg file that hinders the overwriting? And do you in any place do something like USE DBF() AGAIN EXCLUSIVE. When you do something like that a table opened shared is changed to being opened exclusive, that could hinder to copy it.

To make sure it's not the usage of the local file, why don't you first close it in any case, so

USE IN SELECT("bill")
Copy File (Sys(2003)+"\billing.cfg") to ("F:\sys\billing.cfg")

If that still does not work, are you sure you're the only user overwriting the central cfg? This construct is not capable to support multi user environments. Unlöess F: is a share mapped individually per user and only available for that user, but then I'd rather use the roaming profile folder of a user which would unbind you from copying the file at all, Windows would handle that between user sessions even when users roam, as the name roaming profile suggests.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[gryff15]

The local unit is going to be used by multiple users through a remote desktop connection since we're working from home due to lockdown.
The main server should be modified because once the users finally work at the office, they will have different PC's. So when one modifies the CFG, it should be updated in the main server, so everybody who will login will get the latest update of CFG to their local PC's.
I will try to use the "USE IN SELECT("bill") and I hope it will work. And thank you so much by the way.

- webrider -

 

[Olaf Doschke]

OK, so there will be a potential concurrent write, though less probable. But then anybody's last change of this config will be the others config, wouldn't it be a) wise to put it in admin hands only or b) let everyone have his own config? I once used a similar system of a centrally stored configuration and that was only maintained by site admins and not anyone and then only read by users.

It's not a nogo to do it your way, but it seems odd to me anyone config change overrules any other one's choices.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[gryff15]

Sorry I forgot to mention that not everybody can access it. Only a few, like the supervisors and managers should modify the configuration. The rank and file employees will not be able to access it but they should get the updated CFG as well.

- webrider -

 

[Olaf Doschke]

OK, that makes sense.

I guess closing the bill alias will work, as indeed COPY FILE does not work on a dbf you have opened, even shared.

Bye, Olaf.


Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Hi,

You use a file "billing.cfg" as a table? That is not very default.
A .cfg file is usually a file which contains the configuration settings.
You should not "use" it as a .dbf, to read a .cfg file you will need a text file reader like notebook a.s.o. in VFP you can read a .cfg file with the command "modify file billing.cfg"
There should not be any reason to copy the a .cfg file between several stations. Just put it there and leave it there.
Now for modifying data in a grid you shall need either a table in a .dbf, a cursor or a view which contain data, with the exception that you are able to name with any other extension, but preferably not with the extension which is in use already like '.cfg'. There are frameworks developed in VFP9 which make use of files with the extension .aab for tables, I don't believe your framework is making use of that facility.
These files containing the data should also not be copied between two working stations. The usual system is you have on your server a central .dbf and on your working station a subset of records in a cursor. After making the alterations to your cursor you update the central .dbf file. Not copy! Just update.
Stay healthy.

Koen

 

[gryff15]

Hi Mr. Koen,

Thank you for your advice and I personally agree. Even I was also surprised that CFG file is used. But I was not the one who created the form in the firsit place. I'm just assigned to do a little enhancement with it and using DBF instead would require me to check all other forms that use the CFG in the whole system.
Also, we use VFP7 for this form.

Best regards.

- webrider -

 

[Koen Piller]

Good morning mr. Webrider626, (hmm funny alias)

The file billing.cfg.

Please open it with VFP7 by two means:

a) modi file billing.cfg
what do you see? or do you get an error?
otherwise
b)
use config.cfg shared
what do you see in that case?

 

[Olaf Doschke]

Since billing.cfg is USED in

USE SYS(2003)+'\billing.cfg' ALIAS bill Shared

(see initial post in the text) it must be a DBF.

This might seem unusual, and indeed the file could also be renamed to billing.dbf, but then all code expecting billing.cfg would need to be changed.
VFP does only add "dbf" file extension, if you use a table without giving the full filename with extension, if you specify one, it can be anything.

Also, you can't USE a file, if it's not a DBF structure, so whoever originally wrote this thought he marks the central config table with CFG file extension.

I don't see any remaining problem, though you could do without both copy routines, if the form would take the dbf from the central location. I assume the DE of forms is working with a local file and that's also OK, no need to change that, even though it would spare you copying the file back and forth at all.

There could be other reasons for this act of copying, for example only putting back all changes at once, and that can also be done with table buffering. Any way, you just introduce more work to adapt to a central file usage.

The problem is solved by closing bill before copying, isn't it?

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[gryff15]

Hi Mr. Koen,

The data of the cfg are just simple texts and stuff, it's more like a plain table.
And yeah, I didn't put my real name here because I don't want my colleagues to recognize me if they happen to stumble upon my threads. Hehe.

Hi Mr. Olaf,

Yes sir. Closing the CFG before copying solved the problem and thanks for that.

Best regards.

- webrider -

 

[Koen Piller]

Webrider,

good morning.
If you are fine with the solution given by Olaf, I would not change it anymore.
Just to make it clear, your billing.cfg is not a plain table as you call it, is a a table, a .dbf file which the programmer of your application has renamed, for unrevealed reasons with the .cfg extension.
Also it is not good practice when u use a table in VFP, to copy it to your working environment. It works but that does not mean it is the most reliable solution. Much better in my opinion is to just open it in VFP, for that we have the commands use and select. Alternatively you can also use a subset of that table into a either local view, or cursor. In case your application than modifies anything to the view or cursor you should update the master table.
On the other hand, it seems you are 'happy working' with your copy-ing procedure and since you do not encounter any errors, I would not advise you to change that working habit. Follow the rule 'if-it-works-it-works' even, as in your case you are using a wrong procedure.
Regards,
Koen

 

[Olaf Doschke]

Koen.

it's a fair conclusion. And you should always weigh the solution you have with any expectable and maybe dreaded problems you could imagine. The worst-case scenario I can imagine, which you can even assume to happen 100% surely someday, is the copy back to the server happens at the same time a client starts and reads and one of them fails. In that case you have lost nothing, as the admin still has the local file he could manually copy over to the server.

Also, as an impact on your work as a developer: Will you have a hard time editing the file data? No, you can even work on the server file directly. Will you ever need to handle the cfg file again in the aspect of how it's shared? No, that's working. Will the way it's handled make updates of the table structure hard? No, you just copy it over to the one central place just like when it was a shared free single dbf file, as admins also read it in at the start.

Any change will take any amount of necessary time, which can always be invested into more pressing wanted new features or bug fixes. And in my experience there always are.

Bye, Olaf.

Edit: Whoever gave this post a star: I really mean it's fair from Koen to address there is a normal solution to acting on central data, simply bind to it. It should be clear copying data to local to work on it and copy it back only is a good enough option as the data stays just a few configuration records and is only modified by admins. Any normal shared data has to be handled by means of what Koen suggested, working on the dbfs themselves or with views. There is a whole topic and book chapter on programming for shared data access and multi-user in the help file. So I give a star for pointing that out, too.

Olaf Doschke Software Engineering

https://www.doschke.name