Error loading File - record number <n>. <formname> ... Load

[zimj]

Hi All,

I'd really appreciate whatever you can tell me about this.

I'm getting intermittent, but long-standing runtime errors showing:
Error loading file - record number {N}. {FORM'S OBJNAME} <or one of its members>.
where {N} is always the number of the Form record, i.e: with Baseclass = "form".

The Error Message can complete in various ways:
Loading form or the data environment: File is in use by another user
Loading form or the data environment: File access is denied {CDX OR DBF FILE WITH PATH}
Parent: File access is denied {VCX WITH PATH}

In just the last 30 days, we've had this on 6 days, sometimes first thing in the morning, repeating up to 9 times before getting success (after multiple exits, rebooting).

We get this on more than one form. One form is by far the most prevalent, though it is probably also the most used. Each form stands alone, not in a Formset.

Each form uses a private datasession with optimistic row buffering for read/write cursors and no buffering for read-only cursors. Tables are opened shared.

We're running VFP 9.0 SP2 on XP Pro or Win7, on an SBS network (MS Small Business Server). The Fox program would have 3 to 12 concurrent.

Many thanks,

Joel

 

[Dan Freeman]

I don't think I've ever seen this error in a runtime application.

Are your users directly running an SCX file?

 

[zimj]

Yes, you're right. Good call.

I realize an app or exe is considered proper, but there are many advantages of not. That is unless doing so leaves us open to errors we wouldn't otherwise see.

Thank you.

 

[Dan Freeman]

Well, you're coming here with errors nobody else sees.

The VFP design tools, such as the form designer, are NOT multi-user tools and that would include running the form from source. There are many ways to handle auto-updates, in-place updates, etc., using app or exe files. Do you need help constructing something like that?

But a more important point: are all of your users running the development version of Foxpro? Have use purchased that many copies?

 

[zimj]

Another good point. I'd need to check about the licensing.

For a fix, am I right that I could just group the system into some multiple executables for easy updating? Is that what you mean by:

There are many ways to handle auto-updates, in-place updates, etc., using app or exe files. Do you need help constructing something like that?

Thank you very much.

 

[Olaf Doschke]

Actually multiple executables are more a problem than a solution for easy updating, they could do faster updating, but how many users do you have?

I maintain an application about 100MB in size including all files and it takes robocopy only a few seconds in mirroring mode to update this app before starting. There are a few hundred users in that LAN and they only start once a day, if nothing throws them off the system, so that's not a hurdle.

As you provide single SCXes you're used to updating them form by form, perhaps. You actually don't do that, when building an application as exe. It should combine all things, recompiling is easy and fast enough and you don't overlook adding the latest version of everything in. In the easiest case you only provide exe plus two or three runtime dlls, you surely will have a smaller footprint than me, or you already would have gone towards an exe already.

Bye, Olaf.

 

[Dan Freeman]

We'd need to know more about the system to even give you a decent guess. So far, I've been guessing around the edges of what you've left out.

If you find that you need more licenses, PLEASE STOP DEAD IN YOUR TRACKS. You do not need more licenses. What you need is an application that is distributed to the workstations rather than people using Foxpro interactively, and that can likely be done with the license you already have. Or not.

Again, we'd need to know more.

For starters, how do people launch your application?

 

[JRB-Bldr]

Quit trying to get around the system and compile the your VFP application into an EXE.

If you have concerns about automatically getting updated versions, when available, to your users you can use an Application Launcher such as:
An Application starter (with auto copy from server into local station).
faq184-4492

Then issues you encounter will be 'normal' issues which we will gladly attempt to assist you with.

Good Luck,
JRB-Bldr

 

[zimj]

I really appreciate all your help. I will assemble a (single) proper build as you suggest.

Some historical answers to your questions (JRB, Olaf, Dan) for your background, before the planned changes:
The source and interpreter-compiled (eg: fxp) files run about 7MB.
We have about 12 users.
All the custom code resides on the server.
Users launch with a shor-cut target: "{path}VFP9.exe" "{path on server + FirstPrg.prg}"
A Database (DBC) is not used.
I am the only one with access to this system, who uses or knows how to use the command window or other interactive/design services.

Thanks for the starter app. It looks straightforward.

While I'm always happy to get more of your guidance, at this point I feel that understand what I need to do and that the pressure for guidance is reduced. Thank you so much for your help and for the promptness and clarify of it. Thanks!

 

[Olaf Doschke]

In regard to FirstPrg, in an exe there only is one, whatever prg you set main in the project manager, shown bold in the list.

You still can have a main.prg with LPARAMETERS tcProgram and use that parameter to start the wanted program from there:

LPARAMETERS tcProgram
DO (JustFile(tcProgram))

I used JustFile(), as you don't need the path anymore, but could recycle your short cuts anyway, using your.exe instead of VFP9.exe as the main exe to start with the same parameter.

Maybe you want to add a menu to manually choose what to run instead or toolbar or form starting prgs.

Bye, Olaf.

 

[zimj]

Yes, Olaf, thanks. My comments were historical, answering what others have asked. Going forward, I'd be moving to your pattern.