Inno Setup - Read-Only 2

[MajklPan]

Hi, I'm following up on the previous thread where the users gave me great advice.

https://www.tek-tips.com/viewthread.cfm?qid=1820175

I currently have a problem with the function of the program, some functions do not work and write the following error:

When I try this in the development environment, everything works, but when I create the installation file in "Inno setup", it says this error.

I thought it was in the rights of a certain file, so I set all the files in the directory to "Permissions: system-full" in Inno setup. Unfortunately, it did not remove this error, has anyone encountered this problem?

Does the rights have to be set in FoxPro even if everything works for me in the FoxPro environment? Or set it differently in "Inno Setup"

Thanks for your help with this problem

Have a nice day

 

[mjcmkrsr]

Hi,

That depends on how the cursor GPTINFO is created.

If you SELECT ... INTO CURSOR you have to add READWRITE at the end of the command.

CREATE CURSOR ... is READWRITE by default

hth

MarK

 

[Mike Lewis]

I don't know what this has to do with Inno Setup. But, in general, the error message usually is the result of trying to update a cursor that was created with SELECT ... INTO CURSOR ....

By default, such cursors are read-only. You need to add the READWRITE clause to the SELECT to make the cursor updatable.

If the cursor is read-only, as well as not being able to update it, you cannot add or delete records or create indexes.

Having said all that, it's not possible to know for sure that this is the cause of your error, as we cannot see the relevant code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

Make sure that no data goes into "c:\Program files" or its subfolders, since these folders are read-only for security reasons.

 

[Chris Miller]

MarK and Mike could point in the right direction, but I wonder.

I know from your previous thread, you inherited all that code. So, in principle, it should all work, aside from a few bugs you might have inherited. 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. You also say this does not fail when you run it all within VFP.

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).

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...

...well, I don't get errors. 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. Runnning a setup you also get that prompt once. 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. The changed DBF and CDX can be found in %userprofile%\AppData\Local\VirtualStore\Program Files (x86)\Northwind.

Now it depends on your UAC settings what exactly happens in your case. Indeed if that redirection is turned off, you get exactly that error. In my case for trying to change customers.dbf:

So, well, Tore is likely right and you're right with your own assumption, that file permissions are insufficient for the users. And "system-full" is not the setting you need for users, it only gives permission to the SYSTEM account of Windows, not any user.

Eidt:

https://jrsoftware.org/ishelp/index.php?topic=dirssection

- this is where you find explained what the first part of a permission paramter means. 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.

But 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. Otherwise, everyone only works on their own local data. 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. 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.

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.

Chriss

 

[MajklPan]

mjcmkrsr (TechnicalUser):
Yes, I haven't found where the cursor is created yet, otherwise it's set to READWRITE everywhere else.

Tore Bleken (Programmer:
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.

Chris Miller (Programmer):
As you write, I shared this code and I don't have much experience like you.
I didn't introduce a new one, just the modifications you advised me and the program works in VFP.

I tried installing the program only in the C directory and also in the Users directory, this did not solve the problem.
Thanks for posting the link to the thread, I did this setup too and just to be sure I set all the files to Permissions: users-modify and installed to Users, the error message is the same.

Most likely I think it will be in the settings somewhere in VFP, but I'm not sure.

Thank you for your help

EDIT:
I found the code for "opening" in procedures and functions, maybe it could be here, but I don't know about it.

PROCEDURE Otevri *Open
	IF MESSAGEBOX("Odstranit všechny záznamy ?",36,"Měření GPT")=6
		SELECT GptEvTras
		ZAP 
		SELECT GptInfo
		ZAP 
	ENDIF 
	IF DIRECTORY(MemoCestaSestav)&&NOT EMPTY(MemoCestaSestav) &&FILE(MemoCestaSestav)
		SET DEFAULT TO (MemoCestaSestav)
	ENDIF 	
	OtevriInfo=getfile("DBF", "InfoTrasy")
	SET DEFAULT TO (cCestaProgramu)
	IF NOT EMPTY(OtevriInfo)
		MemoCestaSestav=LEFT(OtevriInfo,RAT('\',OtevriInfo)-1)
		HIDE window gptinfo
		APPEND FROM (OtevriInfo)
		COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
		COUNT TO Nemereno FOR EMPTY(datum_cas)
		SUM draha_konc TO DelkaKm
		OtevriInfo=LEFT(OtevriInfo,LEN(OtevriInfo)-1)
		SELECT gptevtras
		APPEND FROM (OtevriInfo)
		SELECT gptinfo
		replace info WITH ALLTRIM(STR(RECNO())) all
		GO top
		SHOW window gptinfo REFRESH top
	ENDIF
	SET DEFAULT TO (cCestaProgramu)
ENDPROC

 

[Chris Miller]

Did you check how permissions end up after the setup?
Also, if you do a changed setup on a computer which already had a setup, I don't know how Inno handles already existing files.
Your error message provides the info that the error arises in GPTINFO.COMMAND4.CLICK. That's the code we should look at.

Now, please read to the end how to get to the code section, before you waste time:

So GPTINFO must be a form, which you can find in two sections of a project, depending on whether it is an SCX form or a form class in a VCX class library or even a form class definition in a PRG, so indeed that's not straight forward to find, when you don't know the project. But look for the most commonly used variations, first: SCX forms. You can find them in the All tab, of course, where you open up the treeview node for Documents to find subnodes forms, reports, and labels. Or, as you know from that treeview sructure now, you find forms in the Documents tab of the project manager window under forms.

Is there a gptinfo form? Then open that up and find a button called command4. There have to be at least 4 buttons and they are named automatically to command1,2,3,4, etc, in the order they are added to the form, not necessarily in geometrical or reading order. That means, it could be any button. You see, that's one flaw of form design, if the button would have been renamed to its purpose it would be easier to find it. I mean, it could be simple and the caption is still Command4, too, but you will typically set the caption to something more user-friendly.

Instead of going through all the buttons you can open the properties window while you have the form open in the designer, and then drop down the combobox at its top. This will show yo the form structure as a treeview and you can see all objects names there and pick command4. Now in the methods tab you can find the click method, doubleclick on that and the code editor will show you that method. Watch out, the code window could end up behind the properties window.

And now you find the code causing the error in line 2. I bet there is nothing wrong with the code, it will be an UPDATE or REPLACE modifying the workarea that has the gptinfo.dbf opened in it. You won't program this for a table you intentionally open with USE gptinfo NOUPDATE or similar. this answers your indirect question indirectly, whether it is the code that prevents writing into the workarea itelf. But since this all works inside the VFP IDE, that's not the reason, this code does not step on its own foot.

So, in the end it would likely not even shed more light on what's the problem, if you find the cclick code. It's quite clear you have a file permissions problem.


Chriss

 

[Chris Miller]

A short warning, if you do things along reading tips:

You'll see I tell in the end it's not worth finding and looking at the click code the error message mentions. So the thing to double check is how the file permissions are actually set in the data directory for gptinfo.dbf. The users-modify permission should suffice, but I don't know what inno setups do to already existing files. So to ensure this new setup works the essential steps are - sorry to even point that out: After modifying the setup permissions in the inno setup create the new setup.exe, uninstall the previous installation and then reinstall with the new setup.
Of course you did that, but I know from creating setups with Installshield there can be multiple output folders for setup.exe or msi files or even CD images. You can easily fail to have picked the actually changed setup.exe

So the best first thing to do is look into file permissions of the current installation on a users PC and decide what to do from knowing that. If effectively the user can write to gptinfo.dbf then its worth looking into the code. Otherwise its worth looking into other things. For example then it becomes helpful to find the click code to set a breakpoint for debugging there. While you don't get the error when you run the project code within the VFP IDE, you can stop there i the click and find out what the workarea gptinfo is at that point. And that doesn't shed enough light, you could also add a MESSAGEBOX(DBF('gptinfo')) into the code and build it into the EXE, put that into a new setup and run it at the client to find out where the file is, that the EXE uses at that point.

Chriss

 

[MajklPan]

I would say that this is a complex problem, because this error appears when I close the INFOUSEK window, so it depends on which button I click, so this button appears as an error.
For example: Program witch error: GPTINFO.DATUMKOLEJ, GPTINFO.COMMAND3.CLIK and so on...

This is in the function for button 3:

1 SELECT GptEvTras
2 ZAP 
3 SELECT GptInfo
4 ZAP 

5 COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
6 COUNT TO Nemereno FOR EMPTY(datum_cas)
7 SUM 0 TO DelkaKm
8 thisform.refresh

 

[Chris Miller]

GPTINFO.DATUMKOLEJ, GPTINFO.COMMAND3.CLIK and so on

"And so on" is not helpful here. Also, not knowing the line number for the error in button3.click I can't point out the problem even though you posted the code.

If it's line 4, the ZAP of gptinfo, it just points to the problem we already know, the readonly state of gptinfo.dbf

If a file is readonly or you don't have modification permissions (so it doesn't need to be the readonly attribute of the dbf file), of course, that causes multiple errors in your code. In every place in the code that tries to modify the dbf without the modify permissions. Of course they all error, as they all face the same problem of not being able to modify the DBF file.

Please, check the permissions on the file itself after the setup has been done. That's the only way to know it is the problem. If it turns out the file permissions allow modification, then we could investigate further in the code.

If somebody programs a ZAP of a dbf, then this needs exclusive access to that DBF and I'm sure the programmer made it that way, or you would have had trouble everywhere with previous software versions already. It also points out this software isn't for shared data access, but that's what I would have guessed from the local installation of the data anyway, so no big surprises or problems with the code, just file permissions. Looking into code or finding more places you only confirm more and more, it's a file permissions problem. Add into it that I got the same error message talking about a "cursor" though it was about customers.dbf in my case. The term "cursor" was misleading others to think of readonly cursors you can generate by code instead of readwrite cursors. But this is about the dbf file gptinfo, I strongl suspect and the suspicion just rises.

Chriss

 

[MajklPan]

After starting the window and pressing any button in the INFOUSEKY window and exiting, it will write an error. So I thought it was unnecessary to list them all.
Yes, line 2 is the one I marked in the code.

In the picture above, where I sent the error, this code is for the COMMAND4 button (I marked line 2):

1 old=RECNO()
2 DELETE
3 COUNT TO Mereno FOR NOT EMPTY(Datum_cas)
4 COUNT TO Nemereno FOR EMPTY(datum_cas)
5 SUM draha_konc TO DelkaKm
6 GO old
7 THISFORM.Grid1.SetFocus
8 thisform.Refresh

After installation, I went through the files in the folder, manually assigning them rights for all users, nothing helped.

I also found that if I run just the .exe file in the project folder without creating any installation, the errors occur already here, I think it's to do with the location of the .exe file, where I have it in the main folder and not in Progs folders.

 

[Chris Miller]

this code is for the COMMAND4 button (I marked line 2):

That's DELETE and it also (tries to) write in the gptinfo.dbf file - assuming that is currently selected. DELETE writes a deletion mark into a record, so it's just a modification of the file, too, like REPLACE or UPDATE.

There's the catch with that click4 code. Depending on what was done before clicking it other workareas than gptinfo could be the current workarea. This code forgets to be specific about hat it deletes. Or it is done with the purpose to be able to delete in any workarea previously selected.

We already know what you inherited isn't really a good codebase, but this again just points out file permissions. Sorry, I can only repeat myself here.

I'm aware you said:

manually assigning them rights for all users, nothing helped.

After you make any permissions change, please look into effective permissions: In advanced security settings you have a tool to pick a user, some application user, and see what effective permission he has with your security settings. Use that:

And then, as I already said, find out which file is actually modified by doing Messagebox(DBF()) in the code. For example right before the DELETE command. You will likely need to modify that code to first select the table that the DELETE command should address, but you might also keep it that way to be able to delete in more than just one DBF, if this is meant as aa general delete button. Before we change that, ensure you have solved the data file permissions, though. For the DBF files that matter.

So once more: You get to the effective access taab from foile properties dialog, security tab and going into the "Advanced" dialog. And first find out which DBF() file to look at by running the Messagebox(DBF()) in the installation. It's the easiest way to find out which file is tried to be modified.

Chriss

 

[MajklPan]

I have the properties of the gpt info.scx file in the security tab, this setting.

EDIT: I tried the thing of creating the installation file as a whole project and then after installation I opened this project in Foxpro, the result was the same, it worked for me in foxpro. So it is likely that it will be in rights.

 

[Chris Miller]

Wake up, we're talking about data, not the form.

You have a gptifo.scx form. Yes, but why? Because it's the form for the gptinfo table, the gptinfo.DBF.
You're looking at a totally unimportant file for the runtime error you have. The runtime problem you have is about DATA modifications.
The SCX is in the EXE when you build, it's not modified, it's executed.

I told you put in a MESSAGEBOX(DBF()) in the click code to see which file you have to look at in detail. Why don't you do that?


Chriss

 

[MajklPan]

I looked for other alternatives as well...

Here is the error MessBox when I expected this file to be referenced.

Paradoxically, if I installed the previous version from 2015, which my pre-skinny did, the GPTINFO.dbf file is read-only and works normally in the program.

 

[Chris Miller]

I assume you have erased a part of the filename. But now you know from where the EXE opens its data and in this folder users need file permissions on the DBFs. So the next steps should be straightforward. First look into effective permissions and then figure out how to give users permissions for this tables directory.

That it's all in the USERS directory points out it should be a directory of the profile and be writable to them, but if one user installed the software into his proflie, only that user can use the software, for example. There are some special users like "PUBLIC", which means for all users. As you don't show us more of the path it's again just guesswork.

As you mention an earlier version had a readonly GPTINFO.dbf and it still worked. I don't know how. I faintly remember VFP once didn't care about file attributes, but I'm not sure that's just a myth. If it was working that way, that's a bug MS fixed for VFP. Becasue what I am sure about is from a simple test right now is that VFP9 and an EXE using the VFP9 runtime will cause the same error, if the user has sufficient write permissions on the file, but the readonly attribute is set. So yes, that's also important to be unchecked.

Chriss

 

[MajklPan]

Thank you for the explanation.

so if I understood it correctly, I don't need to programmatically set anything, I should somehow set the gptinfo.dbf file for the user so that it is opened for both reading and writing.

I did something like this and this didn't help.

 

[Chris Miller]

Please, MajklPan, if you set permissions for this usergroup called "Users" and the dbf still can't be accesse, what does this point out?
Use the "effective permissions" feature and convince yourself about the effective permissions one sample user has.

And what did I just say about the readonly atribute? It is indeed important on top of the file permissions that this is NOT checked too.

Also as you might not have got this: C:\Users is the System directory for all user profiles, the next part of the filename determines which user, there are directories for each user of a system. And if the tables are installed into one users profile, you can try as many times as you want to give permissions to all users, a profile is only for one user and stays to only be accessible for that one user.

Chriss

 

[MajklPan]

I have this set up a long time ago, unchecked "Read-Only".
I have no idea what to set in effective access, but full control is set everywhere.

 

[MajklPan]

So I don't have that, unfortunately I don't have excellent English, so translation is difficult for me, and from a professional point of view, it's difficult to understand the meaning of sentences.

Therefore, some of the plot lines are difficult to translate.

Accesses the file where the installation process created the files.
Here:

Thank you for understanding

EDIT:I inserted MesseBox into a certain button and when pressed it calls something in appdata.. so I don't understand this at all..