Yes, that's what I thought too, but I wanted to install it somewhere else, not in the Program files directory, but this option is not there, so I set DefaultDirName=c:\GPT Print reports, which only installed in the C directory, but unfortunately it also nothing changed and the elements don't work.Īs you write, I shared this code and I don't have much experience like you. Yes, I haven't found where the cursor is created yet, otherwise it's set to READWRITE everywhere else. That's all things you need to consider before creating the setup for your application, no matter if it's a VFP application, even, and no matter if you use inno or other tools for creating setups.Ĭhriss RE: Inno Setup - Read-Only MajklPan (Programmer) And even in case this is intended to be data per userr, installing data into \program files (x86)\yourapplication\data\, for example, means this is the same data for all users of the same computer, so real single user data should be stored into the user profile directory, either into a subdirectory of documents within the user profile or within appdata. It depends on what the application is designed for, but multi-user applications sharing data on a file server are more common than single-user applications with each their own database. Otherwise, everyone only works on their own local data. And system is for the local system account, that is not a user account, it's really the local account called SYSTEM of Windows itself.īut the first question to address now is not how to change the permission within the inno setup project to produce a setup that writes the database with sufficient permissions into \program files (x86)\ for users, but whether you actually would need a central place for all the data. this is where you find explained what the first part of a permission paramter means. And "system-full" is not the setting you need for users, it only gives permission to the SYSTEM account of Windows, not any user.Įidt. So, well, Tore is likely right and you're right with your own assumption, that file permissions are insufficient for the users. In my case for trying to change customers.dbf: Indeed if that redirection is turned off, you get exactly that error. Now it depends on your UAC settings what exactly happens in your case. The changed DBF and CDX can be found in %userprofile%\AppData\Local\VirtualStore\Program Files (x86)\Northwind. But after doing that and using VFP9.exe without administrative elevation, I can actually open dbfs and write to them, the data modification gets redirected, though, by user account control redirection. Runnning a setup you also get that prompt once. If I copy the Northwind subdirectory from my VFP9 installation (which I did into c:\ussers\public instead of c:\program files (x86) to avoid having readonly problems) into a new folder c:\program files (x86)\Northwind I get prompted to elevate to administrator permission to be able to copy the files into it. If you install data into the installation directory it must be done with full file permissions on the data files, otherwise you get readonly errors, but let me check how that actually triggers errors. That makes me think Tore has the better point about all files being readonly within the system folder of program files (and program files (x86), too). You also say this does not fail when you run it all within VFP. So unless you didn't introduce new code that fails here, this should not fail on forgetting READWRITE when creating a cursor the code later modifies. So, in principle, it should all work, aside from a few bugs you might have inherited. I know from your previous thread, you inherited all that code. MarK and Mike could point in the right direction, but I wonder.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |