Error 1104: Error reading file in FRX file

[Jay9988]

Hi all,
I have developed desktop app with VFP 9.0 sp 2, and Mysql Server 5.0
Sometimes my app, in one of the form that generate report, came with error "Error reading file in m:\lapis.frx"
and true, the "lapis.frx" is the report file I generated with "REPORT FORM " command

If I try again, it sometimes works normally, so the error is occasionally

I have the error trapping with ON ERROR command, and get 1104 error number on the line of "REPORT FORM" command

I have set the frx file to "included" my Project Manager ( I believe the frx file is not really needed in the deployed machine, am I right? So, why VFP is still searching the frx file ?
But actually, I still copied all the frx and frt files in the deployed machine.

The app folder is actually put on the server which contain the exe and all frx/frt file, and the folder is shared

Is the error because the folder is shared ? (I know that with Mysql database, the exe could also be putd locally on every station)

I have searched this forum and the other forum about this error, but I think the situation is a bit different.

Thank you for your help..

 

[Chris Miller]

If you embed a report inside the EXE - yes, that's a valid approach.

Make your REPORT FORM command only use the FRX stem name. For example in development the repport is c:\projects\yourapp\reports\yourreport.frx, then just program a REPORT FORM yourreport ... Not give any file name. VFP will indeed first look into the EXEcutable for an embeddedd report file thate.

If that still results in such errors, the problem is likely that the runtime fails to access the EXE. You have the wrong idea that at startup the EXE is fully loaddedd into memoery, so VFP will need to have a stable network and be able to access the EXE at any time. In any case, not only because of this specific case, it's better to have the EXE locally installed. You find several ideas to do that in the FAQ section.


Chriss

 

[Chris Miller]

By the way, notce that ERrror 1104 isn't pointing out a missing fle, it points out not being able to currently read. And in your special case that means reading the FRX from within the EXE. It's actually a common problem of residing your EXE file on the server side, if yo search for error 1104 (watch out, though SYS(1104) may also be found as is a totally different thing than ERROR 1104). It's really about the issue to not reach to the file. And it can be due to LAN outages, but perhaps even more comon, because many users read from the EXE from time to time, so there is a concurrent usage of the EXE leading to such problems on single clients.

This points out once more, why it's better to have an EXE as local file that's not in shared usage.

Chriss

 

[Gerrit Broekhuis]

Hi Jay,

Do you perhaps have more than one user using the same report (FRX) or more programs using this report?
Just check this to be sure.

Regards, Gerrit

 

[Jay9988]

Hi Chris, and Gerrit

Thank you for your input.
@Gerrit, yes, definitely many users running the exe, and very possible at the same time there was 2 or more users generate the same report.

@Chris, yes I feel the problem is because the exe is shared. Because I've already used only the frx name for the REPORT FORM command

I will try to put it on the local machine then...

Many thanks

 

[Mike Lewis]

Apart from the problem that Chris and Gerrit have pointed out, there is a big performance advantage in having a separate copy of the EXE on each local machine. Reports apart, VFP will often need to bring portions of the EXE into memory during execution, and that will be very much faster from a local copy rather than across the network.

A disadvantage of that approach is that it will be more difficult to issue new versions of the EXE. But that can be overcome that with an automated updating process of one sort or another.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Jay9988]

Hi Mike

Thank you for your additional suggestion.

Yes, my reason to put the exe on the server is to easily update with new version
I will search for the technique to automatically update the exec (maybe using .bat files in the startup?)

many thanks

 

[Chris Miller]

my reason to put the exe on the server is to easily update with new version

Well, you can't replace an EXE in this central server location, if even only one user currently executes it. So indeed I would say that makes it harder to update the EXE. There are admin tools that will allow you to override that lock, but in case you copy from a central folder to a local one, the update is always possible and will travel to the users next time they start. Providing the update then is unproblematic.

You have an inverse problem of users not quitting applications. They don't get the update. So you could argue forcing users out of their usage of an outdated EXE is always a problem, whether they use exactly that EXE or their local copy of it. You finally want them to update. It's the problem with concurrent file access even of the EXE itself, that makes it quite a necessity to copy local and run. You run on the local CPU anyway, you don't switch from Server execution to client execution, you change from running an EXE that's stored in some server share to running that EXE from a local drive. And that means no complications of the type of ERROR 1104.

Chriss

 

[Mike Lewis]

You might like to look at my article, Using the Software Update Wizard with Visual FoxPro, for one idea for how to propagate an update of the EXE. But it's only a suggestion. I wrote the article over ten years ago, and to be honest I've never used that product myself. I have written my own code to handle this situation, as no doubt many others have done. But I hope the article will give you an idea of what is possible.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Jay9988]

Thank you Chris and Mike..
@Mike: Thank you for the idea, I will look into it