Print Thread
destructive behavior on workset.
#64563 04/25/23 09:11 PM
Joined: Feb 2003
Posts: 126
Portland, OR. USA
F
fidelfs Offline OP
Member
OP Offline
Member
F
Joined: Feb 2003
Posts: 126
Portland, OR. USA
I like the idea of workset and I use it a lot.
Many other tools have the same idea (not oracle tools), i.e. vscode, webstorm, etc.
they keep saving the version somewhere so you can close the program without saving. You choose when to save it locally.
That is what I love this functionality.

The behavior causing issues only happens with pl/sql developer tool. It has never happen in any other tool for different brands.

I work from home so I need to use VPN to connect to the database. From time to time, the connection is dropped or crashed. It should not affect the local workset saving in the local computer, but it does. When Pl/SQL developer detects that it does not have a connection with the database it freezes and windows starts sending popups warning the software lost connection and I have the choice to cancel or wait. Either option will cause the one or more file from the workset to corrupt. Sometimes, the file disappear completely without trace. It is not in the trash can, or anywhere else. I am talking the real file in my local.
Another time, the file still there, but it is empty.

Why workset depends on a database connection? I don't see the reason. I understand when compiling it needs to connect, but to keep a local version?
I have lost so many files. I tried to git commit and keep a version in gitlab, but sometimes I loose hours because this behavior.

The other behavior that it is not fixed, it is the slowness to display all the files, I am talking really slow. I minimize the tool and call it again from the taskbar (it has not been closed, only minimize). It takes long time to display the tool all over again. It does not matter if it is the only tool loaded into the system or not.

This slow display behavior has caused the tool to "not able to communicate" and then the destructive behavior takes place.

I think this needs a fully rework trying to find a solution.

Re: destructive behavior on workset.
fidelfs #64565 04/26/23 08:14 AM
Joined: Aug 1999
Posts: 22,216
Member
Offline
Member
Joined: Aug 1999
Posts: 22,216
A workset depends on a database connection because it can contain database sources. It needs a database connection to check if the source has been changed since it was included in the workset, or, if the workset version was unchanged, to get the original source. If you only work with source files from the file system, then a database connection is indeed not a requirement.


Marco Kalter
Allround Automations
Re: destructive behavior on workset.
fidelfs #64567 04/26/23 12:20 PM
Joined: Dec 2022
Posts: 6
G
Member
Offline
Member
G
Joined: Dec 2022
Posts: 6
It would be better if we could flag each window whether or not it uses a local file. If Yes, it makes no sense to check the database connection when a workset is opened for that window. A default global value for this flag could resides in Settings.


Moderated by  support 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.1.33 Page Time: 0.059s Queries: 14 (0.037s) Memory: 2.5065 MB (Peak: 3.0406 MB) Data Comp: Off Server Time: 2024-05-12 08:40:59 UTC
Valid HTML 5 and Valid CSS