Hi Geert, I located the trace files. Not sure why, if they are such a valuable diagnostic tool, that they are stored in the AppData Temp folder. I also found that every report I've looked at since upgrading to 3.x has a corresponding html file in that Temp folder, too. It might be worth reconsidering the location for those files along with a retention schedule. But anyway...
Oh, and another suggestion - the trace file should have a version stamp, not just a time stamp. I can't really tell the exact point at which I upgraded by just the time stamp. I believe it was early in the day on either Tuesday or Wednesday of this week, but a version stamp would completely eliminate doubt. I only have 13 trace files dated from 2018.06.04 to today, 2018.06.08. These dates to include the upgrade from 2.?.19 to 3.0-118-gd2ef5fd0f+ (2018-04-28) The vast majority of trace files only say: * 05:58:17 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) One of them pre-upgrade (I'm pretty sure) says: * 06:30:48 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) * 06:31:40 WARN <Gtk> Could not find the icon 'gtk-file'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases >From the morning of Wed 2018.06.06 which may be the time of upgrade: * 06:25:32 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) * 06:44:17 WARN <gnc.core-utils> Could not locate file AUTHORS * 06:44:17 WARN <gnc.core-utils> Could not locate file DOCUMENTERS * 06:44:17 WARN <gnc.core-utils> Could not locate file LICENSE * 07:07:15 CRIT <gnc.gui> [gnc_ui_file_access_response_cb()] Invalid response The very next trace file, after I accidentally left the program running all day says: * 10:36:13 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) * 18:45:07 CRIT <gnc.backend.dbi> [GncDbiSqlConnection::begin_transaction()] BEGIN transaction failed() * 18:45:07 CRIT <gnc.backend.sql> [GncSqlBackend::commit()] begin_transaction failed The one that was apparently created just now when I started the program says: * 06:11:57 WARN <gnc.app-utils> Could not spawn perl: Failed to execute child process (No such file or directory) * 06:15:05 CRIT <gnc.gui> [gnc_ui_file_access_response_cb()] Invalid response There was no popup about moving metadata following the upgrade. I never experimented with the dev series. I will re-check the release notes, but as I upgraded to 3.1.x, hopefully I just skipped over any earlier 3.0 issues. Thanks! On Thu, Jun 7, 2018 at 10:01 AM Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > Op donderdag 7 juni 2018 16:48:11 CEST schreef Thomas Forrester: > > Hi Geert, > > > > The old saved-reports-2.4 file was found in the %USER%\.gnucash folder. > > None of the 3.-variations you mention apply here. > > > > When I located the 2.4 file, I backed up the new 2.8 file to take it > > completely out of the picture, then copied the 2.4 file over to > > %APPDATA%\GnuCash > > to see what would happen. If nothing, I figured I'd rename the file from > > 2.4 to 2.8, but it worked with the 2.4 name. Is this alright? Will it > > cause problems later? Is there a better way? > > > No. That is what the migration should have done as well. > > > When I upgraded to 3.x, > > that is the environment it found itself upgrading. > > Ok, do you think you could still find the trace file gnucash generated the > first time you started gnucash 3.x ? Where to find trace files is > described > here: http://wiki.gnucash.org/wiki/Tracefile > > Secondly, the first time you ran gnucash 3.x did you get a pop up window > explaining you your metadata was being moved to a new location ? > > And lastly, did you ever experiment with the 2.7 development series on > your > current machine ? > > > > > I'm slipping out of scope on the OP topic here, but (in the Windows > > environment, if that matters) what is the best practice for data storage? > > Am I setting myself up for problems using MySQL? Has my use of MySQL > > contributed to the missing report situation on upgrade to 3.x? > > > Xml is still considered the most stable format in general. That is > independent > of your OS. On the other hand the db formats are improving with each > release. > We did find a few issues in gnucash 3.0 and 3.1 in this area. So be sure > to > read the release notes for more details. > > Regards > > Geert > > > _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
