FMA 11 Windows Runtime "Locked" Permissions Issue

[Otis]

Ok, I've been racking my brain on this one and can't figure it out.

I have a solution I built in Filemaker 11 Advanced, and built a runtime on my Windows XP system. I'm using the latest 11.0.2 FMA 11 for Windows.

I have a client using 64 bit Windows 7.

They have permissions to add records, change the password, etc., but when trying to simply CHANGE the password, they are getting a message saying: "This action con not be performed because the file is not modifiable."

They can login and use the runtime solution, but changing the password caused this error message.

I'm thinking it has to be a Windows permissions issue to I had them test the following, all of which didn't work:

1. Move the solution outside of "Program Files" (such as into My Documents) since there are strict limitations to this folder. Didn't work.

2. Not just move the solution outside of "Program Files" but never load it in there from the start and from the start create it in "My Documents". Didn't work.

3. Had them check the entire folder, runtime app and data file permissions by selecting right click, choose properties, to ensure "Read Only" was not checked. It wasn't checked.

4. Had them check the entire folder, runtime app and data file permissions by selecting right click, choose properties, go to the "Security" tab and select "Edit" to make sure this user/Admin has "Full Control" over the access. It didn't change anything.

5. I use Installer Vide to install the product on Windows systems for users. I was thinking that the installer could be the issue. But I simply bundled the entire folder to the end user (no installer) and ran into the same "locked" issue.

Is this something to do with the solution being created by me on an XP system, and they're using Windows 7 64bit?

Any ideas?

I can't believe this is so problematic....argh.

Please help, thanks.

[TheTominator]

(1) Are you sure that their runtime is behaving normally aside from this password changing issue? Can the user create new records, edit info in records, delete records, etc? Are these edits properly preserved when the user exits and relaunches the runtime?

(2) Are you able to reproduce the behavior on your Windows 7 installation? Be sure to reproduce exactly your user's configuration for the user accounts (admin, power user, normal user).

[Otis]

Thanks for the reply, TheTominator.

1. I know that from Filemaker's perspective they have full rights to the runtime. This is because I have a splash screen that only pops up if they have full rights to the runtime. If they enter in a login/password incorrectly in FileMaker, they will not see this splash screen.

2. I don't have Windows 7 at all. I have XP.

[TheTominator]

1. I know that from Filemaker's perspective they have full rights to the runtime. This is because I have a splash screen that only pops up if they have full rights to the runtime. If they enter in a login/password incorrectly in FileMaker, they will not see this splash screen.

I'm not asking if they have the appropriate FileMaker access privileges. I am asking if they in fact can actually succeed in typing in data or do they run into a similar failure when they try to do things other than changing their password.

If they cannot actually enter data, then it is probably a Windows permissions issue.

2. I don't have Windows 7 at all. I have XP.

There are lots of differences between installing and running things under Windows 7 (and Vista) compared to Windows XP. In order to get to the root of the current issue and others that your users will likely encounter, you'll need to directly test and use your runtime under Windows 7.

[Otis]

I solved this by checking FMStrs.dls. It turns out this kept defaulting to Read Only during the runtime process.

Also, I had the Windows 7 user install this runtime outside of the Program FIles dir and everything is back to normal and working.

Thanks