 		<cfquery name="d_htax_dataset" datasource="user_login" username="#session.dbuser#" password="#decrypt(session.epw,session.sessionKey)#">
 			delete from htax_dataset where dataset_id =#d.dataset_id#
 		</cfquery>
-
 	</cftransaction>
 
+	delete successful.
+		<p>
+			<a href="taxonomyTree.cfm?action=nothing">home</a>
+		</p>
 	</cfoutput>
-
-
-
-
-
-
-
-
 </cfif>
 <!--------------------------------------------------------------------------------------->
 <cfif action is "mismatch_import">

</cfif>



<!------------------------------------------------------------------------------------------------->
<cfif action is "noSuccessimport">

			$( "#srchBtn" ).click(function() {
				performSearch();
			});
			if ($("#autosearch").val().length>0){
				console.log('go go autosearch');
				// grab the term, stuff it in the search box so as to not confuse people
				$("#srch").val($("#autosearch").val());
				// do nothing for a while, let stuff happen
				// doopty-doo
				// wheeee
				// done yet?
				// hope so

				// and kick off search

				setTimeout(performSearch,1000);

			}
		});
		// end ready function

	</script>
	<div class="importantNotification" style="width:70%">
		<div style="max-height: 10em;overflow:auto;">
			<h2>Read this!</h2>
			<h3>Using the form</h3>
			<p>
				<strong>Doubleclick</strong> terms to expand.
				<br><strong>Check</strong> the box to edit.
				<br><strong>Drag</strong> to re-order.
				<br><strong>Rightclick</strong> to close a node.
				<br>All edits propagate to all children.
			</p>
			<h3>Search</h3>
			<p>
				Search is case-sensitive contains;
				<br>"<strong>Mus</strong>" finds "<strong>Mus</strong>" and "<strong>Mus</strong>tela";
				<br>"<strong>mus</strong>" finds "Microtus oecono<strong>mus</strong>, NOT "Mustela" (but will find "Mustela <strong>mus</strong>tela").
				 <br>Large searches may be slow, and possibly cause local memory problem (but "mus" in Insecta
				 returned 20K usable results in 30s on test).
				 <br>Re-searching while a previous search is still "working" can cause strange behavior.
			</p>

			<h3>Limitations</h3>
			<p style="width:70%">
				IMPORTANT: This form cannot deal with homonyms of any form. You will most likely find these by the presence of weird higher taxonomy.
				If you simply "fix" these, they (and their children!) are exceedingly likely to be subsequently "fixed" by collections using the
				homonym in different ways. Coordinate updates, which may require splitting classifications.
			</p>

			<h3>Weird Data</h3>
			<ul>
				<li>
					Orphaned nodes
					<ul>
						<li>
							On import, terms are arranged hierarchically on a first-come, first-served basis. If you find an abandoned node, it was most
							likely used inconsistently in Arctos data and "someone else got there first." Edit the term, click Source Details and/or
							Arctos Record and click around to find the source of the term. There are eg, turtles cataloged in bird collections, which may
							show up as outliers in "your" dataset. You may simply delete any terms you don't wish to manage - doing so will not affect
							Arctos classification data in any way. (Anything you keep in your dataset WILL affect Arctos classification data when you
							repatriate.)
						</li>
						<li>
							Example: The genus of Nyroca americana (http://arctos.database.museum/name/Nyroca%20americana) was given as "Aythya."
							This results in very strange inconsistencies across all Nyroca (and possbibly Aythya).
						</li>
					</ul>
				</li>
				<li>Non-hierarchical data</li>
				<ul>
					<li>
						The tree will ideally be a continuous progression from kingdom (or whatever your top-level rank is) down to subspecies,
						with every term's children being of the same rank. The tree should load with one term (eg, kingdom), expanding that should
						find only terms ranked phylum (or whatever the second-level term in your classification is), etc. Expanding kingdom
						should never find eg, one phylum and three families. This will almost never be true; children terms of mixed rank
						are from inconssitent hierarchies, and should be rearranged into a single consistent hierarchy.
						Species (and other lower-lever terms which have no (useful) classification may appear at the top of the tree
						(eg, beside kingdom). Given the hierarchical structure of this app, we MAY be able to help with SQL; contact a
						DBA for more information.
					</li>
				</ul>
			</ul>

		</div>
	</div>

	<cfif not isdefined("autosearch")>
		<cfset autosearch="">
	</cfif>
	<input type="hidden" name="autosearch" id="autosearch" value="<cfoutput>#autosearch#</cfoutput>">

	<label for="srch">search <cfoutput>#dataset_name#</cfoutput></label>
	<input id="srch">
	<input type="button" value="search" id="srchBtn">
