| Author |
File Access Problem in C6.1
|
|
| rwmorrison@bigfoot.com 2005-01-03, 3:55 am |
| I have a Clarion app that was working properly in C6.0. I upgraded
Clarion to C6.1 (build 9025), installed hot fixes 9026-9031 and
installed the most recent versions of ABCFree6 and FM2 for C6.1.
Now my app is crashing with these error messages:
Could not get write access to WORKINGD so trying read-only.
File WORKINGD could not be opened. Error: Access Denied (5). Press OK
to end this application.
WorkingData is a .tps file which contains working data. The physical
..tps file is deleted at the end of each run via the remove function.
To try to isolate the problem I add messages to my app and performed
these steps:
1. In Main, the Relate:WorkingData.Open creates the .tps file. I added
messages before and after this statement to ensure the physical .tps
file was created by this statement. The file does not exist before
this statement and it does after this statement.
2. Main uses the start(WorkingDataBrowse) statement to open the browse
for WorkingData. When the WorkingDataBrowse procedure executes the
Relate:WorkingData.Open statement, the app crashes with the messages
listed above.
After the app crashes the WORKINGD.TPS file exists and the only
attribute that is set for the file is Archive, so the file is not set
for read-only access.
Does anyone know of anything inC6.1 that would cause this problem?
| |
| talmadge50@msn.com 2005-01-03, 3:55 am |
| We had the same problem, but I had a client Windows XP machine trying
to open a file on another Windows XP machine's shared drive.
Is this a standalone machine or are you networking? Are you using XP?
Does the user have read/write permission on that machine?
Our problem was identified when the user couldn't write a notepad file
in the working data directory on the shared drive.
The solution was to allow user's who shared the drive to have
read/write access. Checkbox on the shared properties of the folder.
Good Luck
Gary Bennett
rwmorrison@bigfoot.com wrote:
> I have a Clarion app that was working properly in C6.0. I upgraded
> Clarion to C6.1 (build 9025), installed hot fixes 9026-9031 and
> installed the most recent versions of ABCFree6 and FM2 for C6.1.
> Now my app is crashing with these error messages:
>
> Could not get write access to WORKINGD so trying read-only.
> File WORKINGD could not be opened. Error: Access Denied (5). Press OK
> to end this application.
>
> WorkingData is a .tps file which contains working data. The physical
> .tps file is deleted at the end of each run via the remove function.
> To try to isolate the problem I add messages to my app and performed
> these steps:
>
> 1. In Main, the Relate:WorkingData.Open creates the .tps file. I
added
> messages before and after this statement to ensure the physical .tps
> file was created by this statement. The file does not exist before
> this statement and it does after this statement.
> 2. Main uses the start(WorkingDataBrowse) statement to open the
browse
> for WorkingData. When the WorkingDataBrowse procedure executes the
> Relate:WorkingData.Open statement, the app crashes with the messages
> listed above.
>
> After the app crashes the WORKINGD.TPS file exists and the only
> attribute that is set for the file is Archive, so the file is not set
> for read-only access.
> Does anyone know of anything inC6.1 that would cause this problem?
| |
| rwmorrison@bigfoot.com 2005-01-03, 3:55 pm |
| Gary,
Thank you for your reply! This problem is occurring on a standalone
PC. It is my development PC and I have full permission on the
directory where the file is created. It holds my other .tps files and
I have no problem accessing those files.
Randy Morrison
| |
|
| Randy,
I had a few similar problems when moving from 6.0 to 6.1 and found that
liberally sprinkling Access:Filename.Usefile() in the problem areas
took care of the issue.
I assumed that the problem was caused by the timing differentials (due
to threading, or ?) in 6.1.
Rich Knoch
www.compulink-ltd.com
| |
| rwmorrison@bigfoot.com 2005-01-04, 3:55 pm |
| Rich,
Thank you! I found this suggestion in another thread (probably
yours!). I added a usefile() statement immediately before the point at
which the app was crashing, but it did not help.
Based on the threads I found, several others have experienced this
problem. Has anyone heard anything from SoftVelocity on this issue?
It is frustrating and discouraging when an upgrade breaks working code.
Randy Morrison
| |
|
| Randy,
I had a few similar problems when moving from 6.0 to 6.1 and found that
liberally sprinkling Access:Filename.Usefile() in the problem areas
took care of the issue.
I assumed that the problem was caused by the timing differentials (due
to threading, or ?) in 6.1.
Rich Knoch
www.compulink-ltd.com
| |
| rwmorrison@bigfoot.com 2005-01-06, 8:55 pm |
| Rich,
Thank you! I found this suggestion in another thread (probably
yours!). I added a usefile() statement immediately before the point at
which the app was crashing, but it did not help.
Based on the threads I found, several others have experienced this
problem. Has anyone heard anything from SoftVelocity on this issue?
It is frustrating and discouraging when an upgrade breaks working code.
Randy Morrison
| |
| rwmorrison@bigfoot.com 2005-01-08, 3:55 am |
| Gary,
Thank you for your reply! This problem is occurring on a standalone
PC. It is my development PC and I have full permission on the
directory where the file is created. It holds my other .tps files and
I have no problem accessing those files.
Randy Morrison
| |
| rwmorrison@bigfoot.com 2005-01-10, 8:55 am |
| Gary,
Thank you for your reply! This problem is occurring on a standalone
PC. It is my development PC and I have full permission on the
directory where the file is created. It holds my other .tps files and
I have no problem accessing those files.
Randy Morrison
| |
| rwmorrison@bigfoot.com 2005-01-10, 3:55 pm |
| Rich,
Thank you! I found this suggestion in another thread (probably
yours!). I added a usefile() statement immediately before the point at
which the app was crashing, but it did not help.
Based on the threads I found, several others have experienced this
problem. Has anyone heard anything from SoftVelocity on this issue?
It is frustrating and discouraging when an upgrade breaks working code.
Randy Morrison
| |
|
| Randy,
The new threading model is what causes this, I think. I believe, It
(the threading model SoftVelocity implemented) is so fast that code
which did execute correctly (open, update, close, etc.) now needs some
help opening the file.
Personally, I like fast code and solid apps - - - and, after tweaking
your code that's what you get with SoftVelocity - - - I like that, but
it does cause us developers some extra work.
Rich Knoch
www.compulink-ltd.com
| |
|
|
| Kasper G. Christensen 2005-01-17, 3:55 am |
| > The new threading model is what causes this, I think. I believe, It
> (the threading model SoftVelocity implemented) is so fast that code
> which did execute correctly (open, update, close, etc.) now needs some
> help opening the file.
Huh? A threading model so fast that failing code needs help?? Does that
make any sense? What is "code that doesn't execute correctly? If you
mean normal I/O errors, they should be handled like always. If you
really mean that one can't depend on code executing as it is supposed
to, then we have a serious problem. BTW. I'm not really sure if you can
say that Softvelocity implemented the threading-model, I think what they
are doing, is using the native threads in windows (at least I hope so).
How does one "help with opening the file"? Did you read that the
suggestion to use Filemanager.UseFile() didn't remove the problem that
Randy is experiencing? Do you know what usefile does? I doesn't but I
will check the help next time I get near Clarion.
Best regards
Kasper
--
Besøg mig på nettet: http://www.kaspershjemmeside.dk
| |
|
|
|
|