Repro:
No CPU use at hang, so this looks like callback unliking rather than an infinte loop. This issue also reproduces on Chrome. One thing I noticed is Blank Database.xlsx does not contain a FVS_PlotInit worksheet. However, adding an FVS_PlotInit based on previous .xlsx files I used through an Access to Excel shim with FVS-Suppose simply moves the hang to "Processing sheet 6 name=FVS_PlotInit".
Are there any detailed import logs I can review for diagnostics on what the problem is? C:\FVS\Project_1\FVSOnline.log is uninformative:
sheet = FVS_GroupAddFilesAndKeywords i= 4
sheet = FVS_TreeInit i= 5
sheet = FVS_StandInit i= 6
loaded table= FVS_GroupAddFilesAndKeywords
loaded table= FVS_TreeInit
loaded table= FVS_StandInit
I can't attach the .xlsx here as it contains data which I don't have permission to redistribute. However, I think it's likely I can get permission to email it to an FVS devloper for a look. Would just need to know who to contact (I have Mike's email already).
Hi Todd,
First,thank you for the level of detail in your ticket--very much appreciated. I tested uploading an XLSX just a minute ago and it succeeded (attached in case you want to use it for comparison).
The section of code where the hangup is occurring deals with checking the GAAK table for any unique grouping codes. Given you're using the standard GAAK table provided in the blank database that doesn't contain any, I'm unable to answer why this is happening without using your database to debug the issue.
One likely solution is for you to simply delete the GAAK table, as it is not required anymore in the new FVS system. The R code actually creates one if it is not present, and the code checking for unique grouping codes is only entered if the GAAK table is present upon upload.
If that doesn't work, please consider getting permission to allow me to see what might be happening with your database.
Kind regards,
-Mike Shetles
Last edit: Mike Shettles 2020-08-05
Hi Todd,
First,thank you for the level of detail in your ticket--very much
appreciated. I tested uploading an XLSX just a minute ago and it succeeded
(attached in case you want to use it for comparison). The XLSX upload code
has been untouched and stable for some time, further adding credence to
that suspicion.
The section of code where the hangup is occurring deals with checking the
GAAK table for any unique grouping codes. Given you're using the standard
GAAK table provided in the blank database that doesn't contain any, I'm
unable to answer why this is happening without using your database to
debug the issue.
One likely solution is for you to simply delete the GAAK table, as it is
not required anymore in the new FVS system. The R code actually creates one
if it is not present, and the code checking for unique grouping codes is
only entered if the GAAK table is present upon upload.
If that doesn't work, please consider getting permission to allow me to see
what might be happening with your database.
Kind regards,
-Mike Shetles
On Wed, Aug 5, 2020 at 9:36 AM Todd West twest820@users.sourceforge.net
wrote:
Related
Tickets:
#54Hi Mike, thanks. I was able to install my uploaded xlsx after deleting the FVS_GroupAddFilesAndKeywords sheet from the workbook. However, a trivial no action run comes back with all zeros because FVS doesn't see any of the trees on the plot (it's a trivial setup: 1 stand, 1 plot, <200 trees) even though a look in FVS_Data.db shows they all got copied into the FVS_TreeInit table as expected, the STAND_ID column matches with the FVS_StandInit table, and the stand expansion factor matches the plot size (INV_PLOT_SIZE = 2). The component dropdowns aren't populating either so, for example, I couldn't specify any management if I wanted to.
So something is still wrong. If it's helpful, the <guid>.out has</guid>
** FVS08 WARNING: TOO FEW PROJECTABLE TREE RECORDS. PROJECTABLE RECORDS: 0;
INVERSE OF FIXED PLOT AREA= 300.0; BREAK DBH= 5.0
which is off by a factor of 150 for the expansion factor and break DBH is set to 999 as usual for fixed plots rather than 5. I'm also getting
** FVS03 WARNING: FOREST CODE INDICATES THE GEOGRAPHIC LOCATION IS OUTSIDE THE RANGE OF THE MODEL. DEFAULT CODE IS USED.
STDINFO FOREST-LOCATION CODE= 618; HABITAT TYPE= 52; AGE= 0; ASPECT AZIMUTH IN DEGREES= 0.; SLOPE= 5.%
ELEVATION(100'S FEET)= 35.0; REFERENCE CODE=
even though 605 is definitely a valid forest for FVS-WC and the stand is getting mapped to the longitude and latitude I specified that's definitely on the forest. The aspect, slope, and elevation are all different from FVS_StandInit too. So maybe the run is not reading the stand table for some reason even though the browser part of FVS seems to be aware of it.
The rest of the logs appear uninformative and it looks like the temporary .db created for the run gets deleted, so that might be difficult to check.
The GAAK in FVS_Data.db seems OK to me.
Database
DSNIn
FVS_Data.db
StandSQL
SELECT * FROM FVS_StandInit
WHERE Stand_ID= '%StandID%'
EndSQL
TreeSQL
SELECT * FROM FVS_TreeInit
WHERE Stand_ID= '%StandID%'
EndSQL
END
Please send me your database.
Hi Todd,
The issue boiled down to an absence if a required "All_Stands" grouping code missing from the "Groups" column in the StandInit table. One I added that (i.e., "All_Stands Location") it ran without error. I've attached the database withh that addition.
This illumiinated the need to add the same macro that is in the Blank_Database.accdb, that automatically includes that code for each stand entry, into the Blank_Database.xlsx file you are using. It's an easy grouping code to forget. I will make sure that gets included into the next release coming out in late September.
This also pointed out that it is still possible to add a stand into a run that doesn't have this code, but that all component windows are still frozen as they are when zero stands have been added (the windows are unlocked by that "All_Stands" code). So I might even add a check during upload for that code, and have a warning thrown for the absence of it. Heck, I might even just add it in automatically, if not too herculean of a task (my plate is mighty full these day, to say the least).
Either way, let us know if you have any other questions.
-Mike
Looks good so far as data flow (I'll take a close look at the predicted growth rates tomorrow), thanks Mike.