VegBank

I have confirmed that this is indeed happening-- the ordering gets messed up because each table is run in the order of tables (what order of tables, I don't know). Further, it seems that they are sorted in alphabetic order, not in order of the numeric keys in SQLStore.

So, the keys in SQLStore are like so:
dnrm-[table]-[sequence #]-[human readable description]

We should run all of the denormalizations, but in the order of [sequence #] not grouping by tables. The offending code is here:
vegbank/src/java/org/vegbank/common/utility/DenormUtility.java
The method init() is called and it "sorts" by table then sequence ID. This is called by LoadTreeToDatabase method runDenorms(), which itself loops through tables, but instead should call a new method in the DenormUtility which runs through all denorm statements in order, rather than requesting each table.

One SQLStore statement is wrong, I'm removing that in SQLStore now.

The implications of this is that plots are not properly denormalized and thus are embargoed (at least partly) by default.

the denormutility now builds a vector of all of the keys in the sqlStore.properties file and sorts them by the sort value. When a subprocess needs to run denorms, it can now just "queue" a tablename. after all of the tables it wants to denormed are queued, the execute() method is called and denormUtility first orders all of the queued tables in the order they are in in the ordered vector, then runs the denorms. This appears to be working and it makes denormalization much more effective (since now it's running the sql statements in the order in which they were designed to be run).

Original Bugzilla ID was 2497