We have application set up on Openedge 10.1c on Solaris 10. We are planning a migration to 10.2B on Solaris 10 to Solaris 11.
Do we need to re-compile all programs due to OE and OS version change?
Do we need a dump and load instead of a dB refresh?
No, you are not required to re-compile. Nor is it a requirement to dump & reload the db.
For a point-release upgrade:
shutdown the db
truncate the bi file, if you are extra paranoid make a backup
apply the upgrade (or change the link pointing to the upgraded install directory)
run "proutil dbname -C updatevsts"
restart the db
On UNIX it is very common to have the old version and new version installed simultaneously. You can manage this very easily by using a naming scheme similar to:
/usr/oe101c # the 10.1c install directory
/usr/oe102b # the 10.2b install directory
/usr/dlc # a link to whichever one you want to be "live"
(You can also use the $DLC variable to redirect sessions, perhaps for testing purposes. Many times people use a simple shell script to set the DLC, PATH & PROPATH to dynamically switch between versions.)
You are not required to re-compile. But once you have migrated to 10.2b and you are sure that you are not going to revert it is a "best practice" to re-compile. That way your code can start to take advantage of new features.
Having said all of that - 10.2B is very old. You really ought to be upgrading to OpenEdge 11.something (11.7.3 is current at the moment.)
If you can compile code there is no reason to stick with version 10. Upgrading to oe11 will, however, require a recompile.
You can also upgrade from 10 to 11 without dumping and re-loading. You can just add "proutil dbname -C conv1011" to the steps above.
(Dumping and re-loading may have benefits but that is a different conversation. Migration between versions or platforms is often a convenient time to do it.)
If you are going to ignore me and stick with version 10 at least go with 10.2b service pack 08. That is the very last release of OpenEdge 10 and it has numerous bug fixes and enhancements that vanilla 10.2b lacks.
Changing Solaris versions does not matter with regards to needing to recompile or dump & load.
You should, of course, still test everything and not just take my word for it.
Related
I need to migrate an enterprise production database from a Windows source machine running Postgres 9.5 to an Ubuntu destination machine running Postgres 11.6 with < 15 mins downtime. I plan to do this with pglogical, which requires the extension being loaded on both source and destination. I am having trouble with the source side because it is Windows.
I have very little Postgres-Windows experience and can neither find any helpful literature on the specific situation nor can I figure out for myself how to presumably install from source.
I've dug and dug and so far the only answer I've been able to find is "ugh... Windows". It seems like the only way to build from source is using Visual Studio, which I don't have or know how to use.
Sources:
https://www.2ndquadrant.com/en/blog/compiling-postgresql-extensions-visual-studio-windows/
https://postgrespro.ru/list/thread-id/1835275
Alex, the 2ndQuadrant article you link to in your own comment solves this. A few of the project or build options noted there have moved a little bit in the newer VisualStudio Community editions, so I can see where you got hung-up.
Just for kicks I compiled 32-bit DLL on my oldest Windows instance. I included the /Release path so you can grab my DLL & see if it works for you. It's (a) 32-bit because I'm assuming worst-case for an old v9.5 install, and (b) targets Postgres 9.6 because that's what I had installed. Unless there were major API changes though, it should connect to v9.5 without any issues:
https://github.com/mbijon/winpglogical/tree/master
If you find you need a version that entirely matches Postgres 9.5, grab my solution files & VS Community 20xx. Load the project & update the Additional Include Directories in Project Config to target your v9.5 paths. That should be all that's needed to link v9.5 Postgres libs.
I'm trying to make an installer using the Qt Installer framework and when an upgrade is available in the software (checked through our rest API), our software will download the new installer and run it.
This should of course uninstall the previous version first, however, it seems just running it will give you "The folder you selected already exists..." error.
I thought using the maintenance tool that is generated would provide a solution, however, it seems that there is no way to run this with a switch to just do the uninstall. It shows up with the dialogue of uninstall, upgrade... which would confuse the users.
Is there a way to get the maintenance tool or otherwise to uninstall the program, so the update can be run?
EDIT:
If this cannot be done, can anyone suggest a good cross platform installer framework?
Do not try to run the installer again, run the maintenancetool.exe to update. You can make a "silent" update by passing a script to the maintenance tool like this:
#echo off
maintenancetool.exe --checkupdates > checkUpdate.txt
findstr /c:"updates" checkUpdate.txt
if %errorlevel% == 0 maintenancetool.exe --script=script.qs
http://doc.qt.io/qtinstallerframework/noninteractive.html
I've got a problem with my web application. A query that completes in a few seconds in SQLite 3.7.4 on Windows takes a whole 6 minutes in SQLite 3.6.22 on Linux. On the very same database file. It contains a few WHERE NOT EXISTS parts so I can imagine something has been optimised there.
But the SQLite version is fixed on the Linux side, it's bound to the distribution so I cannot update it. When I tried a current Linux binary and uploaded it to the server, the shell just said the file would not exist. It was there, ls found it and it was mode 755 by my own user...
And I can't find that specific version for Windows as well to try it in the other direction. The SQLite download site only contains the very current version and nothing else. There's not even an archive of older releases...
Does anybody know where I can find older versions? Preferably as binary as I don't want to spent hours to get it compiled.
You can check out and compile older releases from the Fossil repository.
When I use Subversion in Cygwin to update some repository, some directories update with success, while some other one gets a failure with the error message:
svn: E200030: sqlite: disk I/O error
When doing svn update again for the same repository, a different directory can get the same error. Sometimes, there is a SVN instruction after the above error message.
This happened due to a change someone wanted in Cygwin's SQLite package. I was the maintainer of that package when this question was asked, and I made the change that caused this symptom.
The change was released as Cygwin SQLite version 3.7.12.1-1, and it fixed that one person's problem, but it had this bad side effect of preventing Cygwin's Subversion package from cooperating with native Windows Subversion implementations.
What Happened?
The core issue here is that Subversion 1.7 changed the working copy on-disk format. Part of that change involves a new SQLite database file, .svn/wc.db. Now, in order to implement SQLite's concurrency guarantees, SQLite locks the database file while it is accessing it.
That's all fine and sensible, but you run into a problem when you try to mix Windows native and POSIX file locking semantics. On Windows, file locking almost always means mandatory locking, but on Linux systems — which Cygwin is trying to emulate — locking usually means advisory locking instead.
That helps understand where the "disk I/O error" comes from.
The Cygwin SQLite 3.7.12.1-1 change was to build the library in "Unix mode" instead of "Cygwin mode." In Cygwin mode, the library uses Windows native file locking, which goes against the philosophy of Cygwin: where possible, Cygwin packages call POSIX functions instead of direct to the Windows API, so that cygwin1.dll can provide the proper POSIX semantics.
POSIX advisory file locking is exactly what you want with SQLite when all the programs accessing the SQLite DBs in question are built with Cygwin, which is the default assumption within Cygwin. But, when you run a Windows native Subversion program like TortoiseSVN alongside a pure POSIX Cygwin svn, you get a conflict. When the TortoiseSVN Windows Explorer shell extension has the .svn/wc.db file locked with a mandatory lock and Cygwin svn comes along and tries an advisory lock on it, it fails immediately. Cygwin svn assumes a lock attempt will either succeed immediately or block until it can succeed, so it incorrectly interprets the lock failure as a disk I/O error.
How Did We Solve This Dilemma?
Within Cygwin, we always try to play nice with Windows native programs where possible. The trick was to find a way to do that, while still playing nice with Cygwin programs, too.
Not everyone agreed that we should attempt this. "Cygwin SQLite is part of Cygwin, so it only needs to work well with other Cygwin programs," one group would say. The counterpartisans would reply, "Cygwin runs on Windows, so it has to perform well with other Windows programs."
Fortunately, we came up with a way to make both groups happy.
As part of the Cygwin SQLite 3.7.17-x packaging effort, I tested a new feature that Corinna Vinschen added to cygwin1.dll version 1.7.19. It allowed a program to request mandatory file locking through the BSD file locking APIs. My part of the change was to make Cygwin SQLite turn this feature on and off at the user's direction, allowing the same package to meet the needs of both the Cygwin-centric and Windows-native camps.
This Cygwin DLL feature was further improved in 1.7.20, and I released Cygwin SQLite 3.7.13-3 using the finalized locking semantics. This version allowed a choice of three locking strategies: POSIX advisory locking, BSD advisory locking, and BSD/Cygwin mandatory locking. So far, the latter strategy has proven to be completely compatible with native Windows locking.
Later, when Jan Nijtmans took over maintenance of Cygwin SQLite, he further enhanced this mechanism by fully integrating it with the SQLite VFS layer. This allowed a fourth option: the native Windows locking that Cygwin SQLite used to use before we started on this journey. This is mostly a hedge against the possibility that the BSD/Windows locking strategy doesn't cooperate cleanly with a native Windows SQLite program. So far as I know, no one has ever needed to use this option, but it's nice to know it's there.
Alternate Remedy
If the conflict you're having is between Cygwin's command line svn and the TortoiseSVN Windows Explorer shell extension, there's another option to fix it. TortoiseSVN ships with native Windows Subversion command-line programs as well. If you put these in your PATH ahead of Cygwin's bin directory, you shouldn't run into this problem at all.
Having encountered the same problem, it appears (in my case at least) to be an interaction with TortoiseSVN. Disabling TortoiseSVN's status icon cache (Settings > Icon Overlays > Status cache "None" > Apply) has everything working just fine for me.
(That obviously doesn't resolve the underlying problem, which appears to be due to the SQL package that Cygwin's Subversion package relies on changing its mode of access. As I write, there's active [if slow] discussion on the Cygwin mailing list about how to resolve this.)
ldd /usr/bin/svn shows that SVN depends on /usr/bin/cygsqlite3-0.dll.
After I change libsqlite3 from 3.7.12 back to 3.7.3, the problem seems to go away. So this may be a SQLite library problem.
Using TortoiseSVN, ticking off Refresh shell overlays at clean up solved the problem for me.
For others reference, I just had this same error (svn: E200030: sqlite: disk I/O error) and found that one of my log files was taking up all my space (and could not write to the HDD because there was no free space).
Run (to make sure you have enough disk space)
df -h
(If you don't delete some large files (I just removed some backup and log files)
Then I just needed to run:
svn cleanup
This resolved the error for me.
After a lot of trial and error (mostly due to lack of documentation and examples) I have managed to create MSI installers that install custom DLLs to WinSxS as side-by-side assembly. There is only one problem: Uninstalling leaves all files (DLLs, manifests and catalogs) in the WinSxS directory. How can or should I best clean that up? I know for sure that nothing else references it.
I have read somewhere that WinSxS has a self-scavenging process that cleans up over time but I could not find more information about that. Can you manually invoke this to clean up stuff?
The only other way I see is manually deleting those bits. First you have to change the owner of all files (assembly, catalog, manifest and their respective directory) from SYSTEM to an administrator account, adjust the permissions and delete them. There are also pieces left in the registry (I think HKLM\COMPONENTS\DerivedData\Components may be one place), but since WinSxS should be treated as opaque it is hard to find any information.
Scavenging isn't exposed anywhere that I know of. I'm not even sure when it is kicked off automatically. Maybe on uninstall of a service pack? Maybe some tool admins can run? I really forget.
Anyway, my suggestion is don't fight it. There are so many twisty turns down there that it just isn't worth trying to get the disk space back. Once uninstalled the bits still in the SxS cache will not be activated so they are just wasting space.
It's a dumb design but blame Microsoft and don't try to overcompensate.
Here is an article, it's kinda complete guide to WinSxS.
So, shortly, you can only uninstall some components (all their versions are in this folder), and you can run Service Pack bridge burning utility (in Vista it is named VSP1CLN.EXE and shipped with SP1). Note, that after execution, you shouldn't be able to uninstall SP or any components to state, prior to SP release date.
No-one is convinced you can - short of a complete reinstall, your bloaty WinSxS directory is there to stay.
There's been a long "discussion" of the problem on technet.
There is no documentation of the format, or any instructions how to remove files that are no longer needed - MS seems to think that disc space is cheap. There is a self-scavenging feature, but no-one's convinced it works, or if it does, it is very conservative (as you'd hope as you don't want it to break your OS)
You can tell is the scavenger is working by checking the "C:\Windows\winsxs\Temp\PendingDeletes." folder, as this is where files are moved by windows update or an installer moves them to - the scavenger just deletes the files in here.
You'll notice that after you uninstall your assembly, while the files are still there, they can no longer be bound to - so they are just "staged", or cached, but not really installed.
Rob & gbjbaanb are correct - you cannot manually invoke a scavenge yourself. Don't try to delete the files yourself - there are multiple places in the registry where they are registered, DerivedData\Components being only one of the many references.
I think the rule for Vista is scavenging is kicked off by the TrustedInstaller service after 10 minutes of machine inactivity, after the last servicing operation (service pack, hotfix, etc). But it's very fickle, so it doesn't run as often as it should. So just be patient, and the files will disappear on their own.
Well i was having some issues as i have an 80GB SSD for my windows and the WinSxs folder was about 12gb's
I was searching the net and i found this command:
DISM.exe /online /Cleanup-Image /spsuperseded
And now my WinSxs is 7gb which was wonderful news.
There are a few updates regarding the cleanup method that apply to newer OS. Check http://www.karafilis.net/winsxs-cleanup