|
Post by stevecc on Jan 19, 2022 0:08:32 GMT 1
Running an old program in dBase IV 1.5
I use the command
run copy &backfiles &files to update files on my local machine
&backfiles is a memory variable that points to multiple files in a network location
N:\2021\117*.*
and
&files is a memory variable that points to a place in the local vdos drive to copy them to:
C:\PRG\DBASE4\ACCTGPRG\DATA\2021\117*.*
When it runs it shows that it finds multiple files in the source location and indicates that it copied them but when i look in the destination I find only one of the files and it has the correct filename but with no extesion ie: 117 not 117.dbf
I want to start using vDos in earnest but need to get this figured out. If I can get this working I think I will be able to figure out the rest of my more minor issues.
Thanks
|
|
|
Post by Jos on Jan 19, 2022 6:53:02 GMT 1
Will be the limited command line processor of vDos, it doesn’t support wildcards in the destination path.
You have to set &files to C:\PRG\DBASE4\ACCTGPRG\DATA\2021.
Or use an alternative command line processor like 4DOS (I suppose that supports wildcards).
Jos
|
|
|
Post by stevecc on Jan 19, 2022 21:33:35 GMT 1
HI Jos Thanks. Are you saying that if I set &files variable to be just C:\PRG\DBASE4\ACCTGPRG\DATA\2021, that the multiple files that are found by the wildcard specification of &backfiles will copy correctly? If that is the case that would be great. But I am thinking that maybe you are not suggesting that. I want to make sure before I try to figure out what 4DOS is etc. BTW - as is probably clear I am working in a network environment and will need to be buying a license, this is the last hurdle I have identified that I need to surmount before deciding if vDos will do what I need. I have tested just about everything else and am finding vDos to work very well.
|
|
|
Post by Jos on Jan 19, 2022 22:05:27 GMT 1
A copy <whatever selection> to a path with (file name) wildcards isn’t supported by the vDos command line processor. An alternative one like 4DOS probably would. But you don't want to rename the destination file names, so wildcards in there are redundant. Only if you would actually for instance want to replace “117” (source) by “118” (destination).
Jos
|
|
|
Post by stevecc on Jan 19, 2022 23:49:14 GMT 1
The &files variable would contain something like N:\2021\117*.* or N:\2021\118*.* or N:\2021\119*.* etc. The wildcard is so that it copies however many files that it finds that match that wildcard spec - usually from 3 - 6 files such as 117.dbf and 117pay.dbf and 117rcpt.dbf etc.
However many there are need to be copied to the destination and the names do not get changed ie if it finds just three files - 117.dbf and 117pay.dbf and 117rcpt.dbf then it should copy those three files to the destination with the same names 117.dbf and 117pay.dbf and 117rcpt.dbf. That's it.
I think you are saying that the source wildcard is fine but the destination wildcard is the problem. And that is why it used to work fine with Win 7 and prior but does not work right with vDos.exe - that the Command line processor in vDos.exe cannot handle the wildcard in the destination file. Is that correct?
When it runs it finds an lists the multiple files in the source directory and says it has copeied them but what if find in the destination directory is just one file. Instead of the three files - 117.dbf and 117pay.dbf and 117rcpt.dbf I find just one file called 117 - with no extension.
I hope this is clearer and will allow you to give me a more definitive answer.
Thanks
|
|
|
Post by Jos on Jan 20, 2022 0:28:01 GMT 1
You’re correct, just loose the destination wild cards, you actually don’t intend to use those. Just to copy some files to another location, without renaming the files.
Jos
|
|
|
Post by stevecc on Jan 20, 2022 2:04:41 GMT 1
That worked. Thanks. Glad it turns out it is not necessary to install/use a different command line processor like 4Dos.
|
|