Do you have a database file named "debug"?
How are you trying to launch your runtime system? Clicking the .exe file or by clicking your .usr file?
I'm trying to run the .exe file.
I don't have a database file named "debug" that I'm aware, but if that's a possible scenario here I can dive into that a little bit. I had another developer working on this for a little bit and it's possible he may have done something like that.
If I understand correctly, you're saying it sounds like it could be making requests to an external FileMaker database that doesn't exist on these client machines we're deploying on..??
Not exactly. I was thinking you might be double clicking a .usr file instead of double clicking the .exe.
If you double click the .usr file, the OS may launch a completely different copy of the executable that may have had "debug" as the primary file that was bound to it but has since been removed/renamed. If that were the case, it would explain this error message as the executable thinks that a file named "debug" is your primary file.
I took a look at my original FM solution. I'm in Manage -> Database and I don't see anything under tables, fields, or relationships that would be looking for a separate databae called DEBUG.
Ah, didn't see your other response before I already checked the database stuff. Anyway, yeah, I'm definitely using the .exe file.
Any other ideas for me? I'm sort of desperate to figure this out as I've got lots of customers waiting on this new version of the software and I can't get FM to generate a working runtime for me.
The error message indicates that it's looking for a primary file named debug. That's a specific file "bound" to the executable when you generate the runtime.
Are you starting "from scratch" each time you generate your runtime solution or are you trying to drop an updated file back into the original runtime folder? (That should work, actually, but since we're getting this error message, I'm thinking you may need to start all over during the run time generation process just to be sure.)
Do you get any different results if you specify a different file extension from the .usr default?
Since you are using 11.03, you shouldn't have needed the run time file update as that applied to the original release of Filemaker 11. Wonder if you need to re-install Filemaker, then use the v3 updater, but leave out this other update...
Yes, I start completely from scratch each time. I'm going to go ahead and remove FM and re-install with the v3 patch as you explain. I'll be back shortly to update you. Thanks!
Looks like that did the trick. Thanks for the tip!
I've got another one for you on this same subject if you don't mind.
I'm on version 3.5 of my software. From 1.0 to 3.3 I've never had this problem, but on my 3.4 and 3.5 (which the only difference is I'm using FM11 now) I can't get past this.
On Windows, I use a simple installer to install the software to the user's machine. It places the application in their Program Files directory as expected...that's where Windows software "lives."
The problem is when I load the software and try to use it I end up with a "this file is not modifiable" error and I'm forced to update the permissions on my application directory so that users on the machine have read/write access. Once I do that everything seems to work great.
Again, I never had this issue on Windows prior to when I started using FM 11. In fact, I've still got my 3.3 installer and when you instlal it to a machine it works great. Remove that and install my new one to the same machine and you're forced to update the permissions. As such, this doesn't seem like a Windows thing as much as it does something different about the way the whole thing is getting packaged up and delivered.
I'd love any information you could provide on that topic. Thanks!
Are you installing the entire folder with database file and all directly to the Program Folder? While I can see the logic to putting an executable there, it's not the normal place to put a data file and your runtime folder contains both. I haven't tried using an installer for this so I don't have any real suggestions here to offer other than installing the folder to a different folder and, if possible, using the installer to create a shortcut to the .exe file on your user's desktop. (You don't absolutely need an installer, but it can make it nicer for the user.)
Yes, I'm just taking everything that FM gives me for the runtime and using InstallShield to make an actual Windows installer out of it, which does put a shortcut on the desktop, allow me to use my own icon instead of the default FM icon, etc. Again, I never had an issue with this up until FM 11, which is odd, because it does seem like more of a Windows/permissions issue than anything else. I'm using the same version of InstallShield that I used with my current 3.3 software and that one works fine. My 3.4 and 3.5 (which were both created with FM11) have this problem.
On that note, the same thing occurs if I simply copy/paste the runtime into the Program Files folder manually. I'm always forced to update the permissions once it's in there, so again, that's why it seems like a Windows/Permissions issue, but then why isn't that same thing happening with my 3.3 that I created in FM10?
As of just this moment, I did a little test. I've got my old 3.3 runtime saved in an archive. I copied and pasted it into my Program Files directory, fired it up and it works great. I do the exact same thing with my 3.4 or 3.5 and I run into this not modifiable problem.
All 3 versions now live in the same place (c:\program files(x86)\usbswiper\version\runtime_files) so the parent folder, usbswiper, has the same permissions. The runtimes themsleves are behaving differently inside this, though, and the only thing different is FM11.
I've been battling this ever since 11 was released. Of course, I jumped right on some of the new features so I can't just go back to 10.
Files can "inherit" write/modify permissions from the enclosing folder. I would think it likely that any such permissions would be set accordingly so I'm suprised this works with the older version.
This should be an obvious questions, so I'll apologize in advance, but what permissions are specified on the runtime folder and its database file before you copy it into your program folder?
If that's not the issue, I think you'll have to configure your installer to put the solution folder in a different location unless there is a way to get the installer to change the permissions on the database file(s).
Here's something that adds even more confusion to the mix.
My runtime includes a general "user" account that my users login with. The first time they login they're asked to change their password. This is the point where I generally get the file not modifiable error and I have to go update the permissions before I can move forward with the software.
This most recent one I created, though, is acting slightly different. I created the runtime, pasted it into Program Files, fired it up and changed my password no problem. I was thinking, wow, it worked! Then, though, the next step is to activate the software which creates a new record in the database. At this point I was slapped with the file not modifiable error again.
So now it's allowing me to update the databases user password, but not actually create any records until I go modify the permissions.
Are those somehow separate? Maybe I can compare the files that handle the users with the file that handles actual database records and see if I can find the difference..??
Looks we posted those last messages at the same time and I didn't realize it until now.
Prior to moving the solution into the program files folder I make sure to set the Users group to have full control. Here's where things get interested. When I copy/paste into program files it loses the Modify permissions. I have to go back in and apply them again.
That's what leads me to believe it's a Windows issue, but then I do the same exact same thing any of my runtimes that I created prior to FM11 and the permissions do NOT get wiped out when pasted into program files. The only runtimes that I have this issue with are the ones that I create with FM11.
It all seems very coincidental to me that they launched FM11 with runtime issues so they released a patch. Then they fix the patch so v3 includes it, but if you look at the runtime solutions that FM10 vs. FM11 creates there are some extra things in the FM11 version (SASL2 and XTPTrans folders) and the only runtimes I'm having permissions issues with are FM11 runtimes.
Doesn't that all seem to add up to a FM11 problem? I'm having a very hard time convincing anybody of this, and I can understand why, but if this was indeed a Windows permissions issue then I'd have the same problem with all my previous runtimes.
Having the installer use a different folder is an option, but it forces to people to install for every user on that machine, which is a hassle, and it's not what people are used to when installing software on Windows. Also, to do that now would be settling for a work-around as I never once had to mess with this until FM11.
Essentially, that's what I gotta do until I find an answer to this, but I'm not going to give up. It simply has to be something with FM11 given all of the signs I'm seeing....unless you can open my eyes to something I'm not seeing..??