Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue updating #245

Closed
lscheffler opened this issue Jan 4, 2024 · 13 comments
Closed

Issue updating #245

lscheffler opened this issue Jan 4, 2024 · 13 comments

Comments

@lscheffler
Copy link
Contributor

πŸ“ Provide detailed reproduction steps (if any)

  1. Run VFP with Thor, do nothing
  2. Run second instance of VFP with Thor (the projects will not load)
  3. Start CFU

βœ”οΈ Expected result

Update

❌ Actual result

πŸ“· Debugging Info

Please add screenshots of

  • Error Message
    grafik

  • Windows from the debugger
    Did not run into debugger.

It simply looks like Thor is still in memory on the first instance.

How to fix this file for common user? (I know how to help myself)

@lscheffler
Copy link
Contributor Author

Additional problem, I think it's related, so no new issue.

  • Start additional VFP instance, starting Thor

Error message (error 17505 in Line 401):
grafik

Sorry; I got error the message through my handler, so no trace visible, thanks to EXECSCRIPT.
grafik

@lscheffler
Copy link
Contributor Author

After closing all VFP and rerun, I got a message that Thor is installed, after that adding subsequent instanced worked.

@lscheffler
Copy link
Contributor Author

Running CFU again (to test #224)
grafik
What? I have done this!

Second instance is open, same failure as in OM ...

@Jimrnelson
Copy link
Collaborator

  1. Run VFP with Thor, do nothing

Does this mean you ran VFP with the new version of Thor or an older version?

The problem in older versions (those before 1.47) is that they left an object open that had all the Thor tables in use.

I believe that this problem is solved if you are running 1.47

All subsequent issues you report here are a result of incomplete installations.

@lscheffler
Copy link
Contributor Author

lscheffler commented Jan 4, 2024

@jim, I have not touched the folder other then through CFU

Step by step

  • Thor 1.46 was installed
  • saw the mails from github
  • started VFP, running Thor on installed my comp, this is 1.46
  • started second instance, running Thor on installed my comp, this is 1.46
    • this is VFP on the same setting structure, with the same foxuser
  • started CFU on second instance
  • Error on the instance with CFU running

I closed the debugger from #246 and run Thor/Configure subsequent, without Clear All. Same error
grafik

I checked the Datasessions, the table is not open, this is the one and only VFP instance. Only the path is nonsense, it's E:\SE\thor\thor\Thor\Tables, not E:\SE\thor\thor\Tables, see
grafik

Update:
Changed menu name

The error on Thor/Configure happens for newly started Thor as well.

@Jimrnelson
Copy link
Collaborator

Understood.

This problem will occur as long as you are using any version before today's (1.47).

That is the version that has the (hoped for) fix.

Of course, there is no way to fix an earlier version.

The problem with the file in use had to to with a different datasession than the default.


When you state a "newly started Thor", the same applies -- until you are running/using 1.47, you'll get this error.

@lscheffler
Copy link
Contributor Author

I think it was clear that all happened after I started CFU to update to 1.47
The whole idea running CFU and the like is testing the changes of 1.47


The problem with the file in use had to to with a different datasession than the default.

As I wrote above. There was no other datasession, no cursor open, and only this instance of VFP active. But the path is wrong.

@Jimrnelson
Copy link
Collaborator

I think it was clear that all happened after I started CFU to update to 1.47
The whole idea running CFU and the like is testing the changes of 1.47

There's the catch-22!

My changes will work when you start in 1.47 and move it to some future (not-yet-created) release.

There is no way for you to test whether they work when moving from some earlier release to 1.47.


There was no other datasession, no cursor open, and only this instance of VFP active. But the path is wrong.

The error you got was an access error, meaning the file existed but could not be exclusively opened. That is because it was still open in the other session, in a different datasession.

@lscheffler
Copy link
Contributor Author

lscheffler commented Jan 4, 2024

I think it was clear that all happened after I started CFU to update to 1.47
The whole idea running CFU and the like is testing the changes of 1.47

There's the catch-22!

My changes will work when you start in 1.47 and move it to some future (not-yet-created) release.

There is no way for you to test whether they work when moving from some earlier release to 1.47.

Not all of it. Some i can test - and none should raise this error. :)

There was no other datasession, no cursor open, and only this instance of VFP active. But the path is wrong.

The error you got was an access error, meaning the file existed but could not be exclusively opened. That is because it was still open in the other session, in a different datasession.

What do you not understand fr0m NO CURSOR WAS OPEN ANYWHERE?? A table is a cursor, that is stored permanently? The files was blocked from whatever, but not from something dealing with VFP TABLES OR CURSORS on the level of VFP data engine.

Sorry for the hickup on the path, to many "Thor" in the path. And me locking for to long into the monitor for today. CU tomorrow. Statement was right, path is wrong.

@Jimrnelson
Copy link
Collaborator

@lscheffler

You had two VFP sessions. The first VFP session you started using version 1.46. That VFP session left an object around which had a private datasession where all the Thor tables were open. (This does not occur is you start in 1.47)

In the second VFP session, you got an error where the update was trying to get exclusive access to a Thor table. It generated an access error for that table because it was trying to access a table left open in the private datasession in the other VFP session.

@Jimrnelson
Copy link
Collaborator

@lscheffler

Earlier in this thread, you described your steps as follows:

Step by step

  • Thor 1.46 was installed

  • saw the mails from github

  • started VFP, running Thor on installed my comp, this is 1.46

  • started second instance, running Thor on installed my comp, this is 1.46

    • this is VFP on the same setting structure, with the same foxuser
  • started CFU on second instance

  • Error on the instance with CFU running

I understand that this occurs when you start your sessions with V1.46.X

There is nothing I can do about that, I do not support that version any more.

If the error occurs when you start your sessions with the latest version, 1.47, that will be worth reporting.

@lscheffler
Copy link
Contributor Author

@lscheffler

Earlier in this thread, you described your steps as follows:

Step by step

  • Thor 1.46 was installed

  • saw the mails from github

  • started VFP, running Thor on installed my comp, this is 1.46

  • started second instance, running Thor on installed my comp, this is 1.46

    • this is VFP on the same setting structure, with the same foxuser
  • started CFU on second instance

  • Error on the instance with CFU running

I understand that this occurs when you start your sessions with V1.46.X

There is nothing I can do about that, I do not support that version any more.

If the error occurs when you start your sessions with the latest version, 1.47, that will be worth reporting.

It fails updating, but you don't care. You might read it as you like. If one clarifies something, you insist on older statements.

The CFU was opened while 4.17 installed, I closed the whole VFP, but this whole process is not stable. The install of 1.47 started before 4.1.2024 19:58, this is the timestamp of the OM of this issue. ANYTHING after that is 1.47 whatever the installer assumes or retries. The failure happens while updating to 1.47, so the update must manage this problem. What do you think I'm reporting?

ok, from scratch

@lscheffler
Copy link
Contributor Author

Runs with 1.47.01 Great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants