ErnestoAleva
Member
Hello all,
I run PL/SQL Developer (Version 14.0.6.1988 - 64 bit) on a multiuser remote virtual machine. Usually I do not close any running application when I'm done with daily job, I just exit the VM. Until few, whenever Developer was exited in an "unclean" way (for example, if the VM was rebooted), next time it was started up the recovery window popped up, and I was able to recover all my work.
Since last summer, nevertheless, this is not working properly. After reboot, the PLS-Recovery folder exists, and is dated at the moment the VM was stopped, but files in there are named desktop.xxx, and are not dated at the same time the folder was, but at some previous moment, all of them files sharing the same date.
Looking at the desktop.cfg file, it points to files named desktop.001, desktop.002, and so on. That is to say, PL/SQL Developer is saving the recovery opened files and the config recovery file with that name "desktop", despite the recovery window will not pop up if the config recovery file is not named with an all-numbers name.
So just changing the desktop.cfg file name to something containing only numbers (like 123456.cfg) makes the recovery window to pop up when opening Developer, but then to recover an old version of the opened files.
Even odd behaviour: A backup from the PL/SQL Developer folder at some moment before the VM was stopped contains up to date (to the moment of the backup, obviously) files, with all-numbers names.
So it looks as if when the VM is being stopped, the contents of the PLS-Recovery folder are being overwritten (by what process? by PL/SQL Developer itself??) with an older version of the files that at some moment PL/SQL Developer created with a name that it will not recognise later...
I am setting up now an automated daily (nightly) copy of the PLS-Recovery folder, as it seems that its contents are being updated, to be able to easly recover last day files, but I find this to be an acceptable temporary workaround, but an awfull permanent solution... Any suggestion on what can be happening? Any suggestion on how to avoid it??
Thanks in advance,
Ernesto.
I run PL/SQL Developer (Version 14.0.6.1988 - 64 bit) on a multiuser remote virtual machine. Usually I do not close any running application when I'm done with daily job, I just exit the VM. Until few, whenever Developer was exited in an "unclean" way (for example, if the VM was rebooted), next time it was started up the recovery window popped up, and I was able to recover all my work.
Since last summer, nevertheless, this is not working properly. After reboot, the PLS-Recovery folder exists, and is dated at the moment the VM was stopped, but files in there are named desktop.xxx, and are not dated at the same time the folder was, but at some previous moment, all of them files sharing the same date.
Looking at the desktop.cfg file, it points to files named desktop.001, desktop.002, and so on. That is to say, PL/SQL Developer is saving the recovery opened files and the config recovery file with that name "desktop", despite the recovery window will not pop up if the config recovery file is not named with an all-numbers name.
So just changing the desktop.cfg file name to something containing only numbers (like 123456.cfg) makes the recovery window to pop up when opening Developer, but then to recover an old version of the opened files.
Even odd behaviour: A backup from the PL/SQL Developer folder at some moment before the VM was stopped contains up to date (to the moment of the backup, obviously) files, with all-numbers names.
So it looks as if when the VM is being stopped, the contents of the PLS-Recovery folder are being overwritten (by what process? by PL/SQL Developer itself??) with an older version of the files that at some moment PL/SQL Developer created with a name that it will not recognise later...
I am setting up now an automated daily (nightly) copy of the PLS-Recovery folder, as it seems that its contents are being updated, to be able to easly recover last day files, but I find this to be an acceptable temporary workaround, but an awfull permanent solution... Any suggestion on what can be happening? Any suggestion on how to avoid it??
Thanks in advance,
Ernesto.
