Hello Gene,
That just raises more questions about what COM object is being used to create the XLS file. Is it shipping with the latest Windows 10 computer? Is it built in to the VFP runtimes? Is this functionality suddenly going to stop working one day after the DLL is identified and removed by some anti-virus software?
All things I don't have time to investigate.
Due to a different control having the same "Unknown COM status" message when attempting to have it write a file to a non-existent path, or a locked file, I have put checks in before calling the functions. Sometimes I think I should change my behavior to write to a temporary file, then move the bytes from the temporary file in to the destination. It would mean a longer save time, but I would be able to deal with anti-virus and on-demand backup tools putting a lock on the files. It's not an exercise for this month.
All things in their time,
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Gene Wirchenko Sent: Monday, June 24, 2019 6:15 PM To: profoxtech@leafe.com Subject: Odd Error Message
Hello:
I got an interesting error message today. It was another example of an error message indicating that an error had occurred with the message not terribly useful for determining the actual error.
Try the following use sometable copy to nothere\nothere\sometable copy to nothere\nothere\somecopy type xl5 where sometable is some table and nothere\nothere is a non-existent subdirectory chain.
The error message for the first copy command is "Invalid path or filename." This is sensible.
The error message for the second copy command is "OLE error code 0x80030003: Unknown COM status code." Huh?
Copying to a directory that does not exist results in an error. You even get a choice of error messages.
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
I would imagine the functionality is baked into the VFP runtimes, I've never had an issue with it failing on any version of Windows, even without Excel installed.
What Alan said. When TYPE XL5 was introduced, it was added because Excel 5 changed the output file format to some COM-based structured storage, iirc. So, VFP is calling some Windows OS-based API calls to create the storage, as it should, and that API gracefully fails ("0x80030003") when you are trying to write to a non-existent directory.
So, VFP is no longer calling the Windows API calls it would with CSV, WKS, XLS or the other formats to create a single file handle and return it to VFP to write to, so it doesn't get the "Invalid path" error return. It's calling a COM function that ought to return a structure pointing to the streams to fill, etc. and doesn't handle the return as well . (Start here https://docs.microsoft.com/en-us/windows/desktop/Stg/structured-storage-star... if you'd like to delve into the horrors of this.)
If Windows drops this core COM support, it's likely not going to be Windows any more, so I wouldn't be sweating this particular feature going away. It would be a good bet that VFP would also not run any more, which is a feature we always have to be planning on... eventually.
On Tue, Jun 25, 2019 at 9:53 AM Alan Bourke alanpbourke@fastmail.fm wrote:
I would imagine the functionality is baked into the VFP runtimes, I've never had an issue with it failing on any version of Windows, even without Excel installed.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Hello Ted, Thank you for the insight. That page was plenty far enough for me to feel like I don't need to worry about it going away. It also reduces the anti-virus and on-demand backup tools concerns.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted Roche Sent: Tuesday, June 25, 2019 10:34 AM To: profoxtech@leafe.com Subject: Re: Odd Error Message
What Alan said. When TYPE XL5 was introduced, it was added because Excel 5 changed the output file format to some COM-based structured storage, iirc. So, VFP is calling some Windows OS-based API calls to create the storage, as it should, and that API gracefully fails ("0x80030003") when you are trying to write to a non-existent directory.
So, VFP is no longer calling the Windows API calls it would with CSV, WKS, XLS or the other formats to create a single file handle and return it to VFP to write to, so it doesn't get the "Invalid path" error return. It's calling a COM function that ought to return a structure pointing to the streams to fill, etc. and doesn't handle the return as well . (Start here https://docs.microsoft.com/en-us/windows/desktop/Stg/structured-storage-star t-page if you'd like to delve into the horrors of this.)
If Windows drops this core COM support, it's likely not going to be Windows any more, so I wouldn't be sweating this particular feature going away. It would be a good bet that VFP would also not run any more, which is a feature we always have to be planning on... eventually.
On Tue, Jun 25, 2019 at 9:53 AM Alan Bourke alanpbourke@fastmail.fm wrote:
I would imagine the functionality is baked into the VFP runtimes, I've never had an issue with it failing on any version of Windows, even without Excel installed.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
At 06:30 2019-06-25, "Tracy Pearson" tracy@powerchurch.com wrote:
Hello Gene,
That just raises more questions about what COM object is being used to create the XLS file. Is it shipping with the latest Windows 10 computer? Is it built in to the VFP runtimes? Is this functionality suddenly going to stop working one day after the DLL is identified and removed by some anti-virus software?
Since I use pretty much vanilla VFP with very little outside stuff, I do not know. Please note that this error is due to the directory not existing. The functionality is there if the directory does exist. I was bemused that the error was different for .dbf and spreadsheet.
Before doing such copying I make sure to create the directory. I have a procedure that creates each needed subdirectory one at a time (which also deals with a bug where capitalisation is lost when creating multiple levels at a time with the VFP MD command). I have posted it before. If anyone wants a copy, just ask.
All things I don't have time to investigate.
Likewise.
Due to a different control having the same "Unknown COM status" message when attempting to have it write a file to a non-existent path, or a locked file, I have put checks in before calling the functions. Sometimes I think I should change my behavior to write to a temporary file, then move the bytes from the temporary file in to the destination. It would mean a longer save time, but I would be able to deal with anti-virus and on-demand backup tools putting a lock on the files. It's not an exercise for this month.
I create the directory explicitly first. It works for me. I am making a number of minor modifications to the system, and this nibbled.
[snipped previous]
Sincerely,
Gene Wirchenko
That reminds me of a bug I encountered once. We had an app that kept crashing and couldn't figure it out.
Finally, I went to the location and did some digging around. It turns out that our code used a file in the Temp folder for some reason I can't remember. Our code checked to verify that the temp folder existed.
What it didn't do was to see if it was read-only or not (this is a "Temp" folder....) Anyway, it turns out that the IT folk at the time had decided to lock down the Temp folder on all machines - but only by making it read only......
The worst part is that, while we couldn't write to the file, we could open it, etc. And when we tried to write to it, it acted like it did, even though it didn't.... But then crashed later when we used it again and the necessary values weren't there...
This was back in the very late 90s, so don't bother asking me for more details....
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Tracy Pearson Sent: Tuesday, June 25, 2019 6:30 AM To: profox@leafe.com Subject: RE: Odd Error Message
Hello Gene,
That just raises more questions about what COM object is being used to create the XLS file. Is it shipping with the latest Windows 10 computer? Is it built in to the VFP runtimes? Is this functionality suddenly going to stop working one day after the DLL is identified and removed by some anti-virus software?
All things I don't have time to investigate.
Due to a different control having the same "Unknown COM status" message when attempting to have it write a file to a non-existent path, or a locked file, I have put checks in before calling the functions. Sometimes I think I should change my behavior to write to a temporary file, then move the bytes from the temporary file in to the destination. It would mean a longer save time, but I would be able to deal with anti-virus and on-demand backup tools putting a lock on the files. It's not an exercise for this month.
All things in their time,
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Gene Wirchenko Sent: Monday, June 24, 2019 6:15 PM To: profoxtech@leafe.com Subject: Odd Error Message
Hello:
I got an interesting error message today. It was another example of an error message indicating that an error had occurred with the message not terribly useful for determining the actual error.
Try the following use sometable copy to nothere\nothere\sometable copy to nothere\nothere\somecopy type xl5 where sometable is some table and nothere\nothere is a non-existent subdirectory chain.
The error message for the first copy command is "Invalid path or filename." This is sensible.
The error message for the second copy command is "OLE error code 0x80030003: Unknown COM status code." Huh?
Copying to a directory that does not exist results in an error. You even get a choice of error messages.
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
You better double-check the error handler! It should not have ignored the write error to that TEMP folder.
To verify whether a folder was writable, you could test write then delete a file in that folder and look for errors. You might need to temporarily use ON ERROR to trap file write errors before restoring the original error handler. I have done this kind of things many times.
But then, why would someone lock down temporary folders? They are supposed to be TEMPORARY! But then, if the limit was on folder size, your code might still failed. So, your program still had to be fixed to detect that. A virus scanner could also produce the same error.
Happy hunting anyway! :)
On Thu, Jun 27, 2019 at 1:05 AM Fletcher Johnson FletcherSJohnson@yahoo.com wrote:
folder....) Anyway, it turns out that the IT folk at the time had decided to lock down the Temp folder on all machines - but only by making it read only......
The worst part is that, while we couldn't write to the file, we could open it, etc. And when we tried to write to it, it acted like it did, even though it didn't.... But then crashed later when we used it again and the necessary values weren't there...
We did have a test to see if the temp folder existed. If it didn't we tried to create it. But it did exist. Given the purpose of the temp folder is to hold temporary data, we didn't bother with code to actually try to create a file, write to it, and then verify that it was written to. I mean, who would ever make a temporary folder read-only????
Anyway, once we figured it out, it was easy to fix.
I don't know why VFP (I can't remember which version we were using) didn't complain about the problem - it's been too long. But I do know that our error handler did not get called and the code happily continued executing even though the write was not actually performed. We used both On Error as well as Try Catch when it was finally added.
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Man-wai Chang Sent: Thursday, June 27, 2019 4:23 AM To: ProFox Email List Subject: Re: Odd Error Message
You better double-check the error handler! It should not have ignored the write error to that TEMP folder.
To verify whether a folder was writable, you could test write then delete a file in that folder and look for errors. You might need to temporarily use ON ERROR to trap file write errors before restoring the original error handler. I have done this kind of things many times.
But then, why would someone lock down temporary folders? They are supposed to be TEMPORARY! But then, if the limit was on folder size, your code might still failed. So, your program still had to be fixed to detect that. A virus scanner could also produce the same error.
Happy hunting anyway! :)
On Thu, Jun 27, 2019 at 1:05 AM Fletcher Johnson FletcherSJohnson@yahoo.com wrote:
folder....) Anyway, it turns out that the IT folk at the time had decided to lock down the Temp folder on all machines - but only by making it read only......
The worst part is that, while we couldn't write to the file, we could open it, etc. And when we tried to write to it, it acted like it did, even though it didn't.... But then crashed later when we used it again and the necessary values weren't there...
Once had a network admin move everyone's "Documents" folder to a shared network path. Then didn't allow anyone to see the contents of the folder above it.
\Server\Share{UserName} was how it was done. The user was able to put things in C:\Users{UserName}\Documents and everything worked. So user couldn't write or see anything in the Share folder. But was allowed full access in their folder.
Getting the SpecialFolder from windows and doing a "SET DEFAULT TO (cDocumentsFolder)" would throw "Invalid path or file name (Error 202)".
Odd errors...
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Thursday, June 27, 2019 4:37 PM To: profoxtech@leafe.com Subject: RE: Odd Error Message
We did have a test to see if the temp folder existed. If it didn't we tried to create it. But it did exist. Given the purpose of the temp folder is to hold temporary data, we didn't bother with code to actually try to create a file, write to it, and then verify that it was written to. I mean, who would ever make a temporary folder read-only????
Anyway, once we figured it out, it was easy to fix.
I don't know why VFP (I can't remember which version we were using) didn't complain about the problem - it's been too long. But I do know that our error handler did not get called and the code happily continued executing even though the write was not actually performed. We used both On Error as well as Try Catch when it was finally added.
Fletcher
Disk I/O errors should always be logged, including secret folders. If you were not allowed to log that error, better leave the company before the errors hurt your reputation and career. Find a regular job that's normal. :)
On Fri, Jun 28, 2019 at 4:57 AM Tracy Pearson tracy@powerchurch.com wrote:
Once had a network admin move everyone's "Documents" folder to a shared network path. Then didn't allow anyone to see the contents of the folder above it.
\Server\Share{UserName} was how it was done. The user was able to put things in C:\Users{UserName}\Documents and everything worked. So user couldn't write or see anything in the Share folder. But was allowed full access in their folder.
Getting the SpecialFolder from windows and doing a "SET DEFAULT TO (cDocumentsFolder)" would throw "Invalid path or file name (Error 202)".
I would always exercise caution in all file i/o codes and walk that distance!! I would argue with my boss about that extra distance.
Anyway, the problem might bite you again, or someone in place of you. Good luck then! :)
On Fri, Jun 28, 2019 at 4:38 AM Fletcher Johnson FletcherSJohnson@yahoo.com wrote:
We did have a test to see if the temp folder existed. If it didn't we tried to create it. But it did exist. Given the purpose of the temp folder is to hold temporary data, we didn't bother with code to actually try to create a file, write to it, and then verify that it was written to. I mean, who would ever make a temporary folder read-only????
-
Alan Bourke -
Fletcher Johnson -
Gene Wirchenko -
Man-wai Chang -
Ted Roche -
Tracy Pearson