Here's an odd one maybe one of you seasoned developers can figure out: I burned a runtime for a client that's been working well for them for over a year. Recently, they copied the whole runtime file to a new machine and when they launched the runtime they got the attached error message. After the user clicked OK, FM asked them to find the USR file. The user selected it from the list, then double-clicked the USR file icon--the runtime launched.

What would cause that? Is there a fix/patch I can make short of re-burning the runtime from scratch?

TIA for your help!

Rich

I notice that's a VISTA message - were they originally on XP?

Good question! I created the original runtime in XP--and it works fine on my Vista machine. I asked your question of my client and he replied, "The old server OS was Netware 6.0, the new one is Novell Open Enterprise Server 2 running a Linux kernel, NSS volumes in both cases."

He goes on to say,"However, given that we can copy it to the local hard drive and see the same behaviour, I doubt the server OS has anything to do with it." So, they've parked the runtime on a server (I know--don't say it), but when I tried it on a standalone machine (my Vista computer), the same problem arose.

Just for my education: If the USR, Application, and support files are both created and lie within the same runtime folder--which in this case they do--even with a different OS what would cause them not to "see" each other? I imagine, perhaps incorrectly, that FM would look for its needed files within the same directory/folder, first, then look elsewhere for them...assuming the filepaths aren't hard-coded in to look for them elsewhere.

Edited January 20, 200916 yr by Guest