Answer: Work on the original version of Foxhound began in March 1998. Back then it was called the RisingRoad Dictionary, and it used Oracle PL/SQL scripts to read the catalog views and generate static HTML containing the CREATE TABLE text for each table in a separate page. These pages included hyperlinks for rapid navigation up and down the parent-child foreign key hierarchy.

The original target audience was application programmers working with an enormous Oracle database at the Princess Margaret Hospital in Toronto. The database was so big and complex that graphical diagrams produced by tools like ERwin were virtually unusable by the programmers.

Graphical tools don't scale well; that is just as true today as it was back in 1998. Following foreign key chains on a diagram is very difficult when there are hundreds or thousands of tables, and any attempt to include the level of detail necessary for a programmer (physical data types and constraints for every column) instantly makes a diagram so large it won't fit on any wall let alone a desk. Subsetting a diagram never seems to work; it always seems to leave out stuff the programmer needs to know.

On the other hand, a text-based display plus hyperlinks and the browser's Back and Forward buttons are ideal for navigating a large database layout... and there's no shortage of screen real estate when you're showing one table at a time, even with all the physical details included.

Foxhound then went through a stage as a multi-platform (Oracle, SQL Server, DB2, SQL Anywhere) documentation tool with the addition of table- and column-level comments stored in its own database (SQL Anywhere).

Eventually, comments were dropped (little demand), as was support for multiple target platforms (too difficult), and Foxhound became a SQL-Anywhere-centric tool. SQL Anywhere's built-in HTTP server made it possible to display HTML on the fly rather than generate static HTML files that rapidly become out of date.

Over the years Foxhound has gradually evolved into a consultant's tool for investigating a client's database: how many tables, what do they look like to a programmer, what are the relationships, how do I get there from here. Foxhound grew to answer questions like how many rows, how much table/index/extension space is this table taking up, what's the average row size in terms of disk usage, where are all the database files and how badly fragmented are they.

The concept of "curiosities" was added: this database doesn't have any clustered indexes, that table doesn't have a primary key, these columns have the same names but different data types, that foreign key has a cascading action, these database options have been changed from their default settings... and this database still has OPTIMIZATION_GOAL set to 'First-row' which might explain why that query takes three hours instead of three minutes.

Then, in early 2007, something really big happened to Foxhound: The "Display Schema" button was joined by "Monitor Database" and a dynamically refreshed HTML display showing what's happening inside the server. By the summer of 2009 the Monitor was producing Alerts and All Clear messages about the availability of your target database and twenty-eight other conditions that fall short of an actual crash.

And now it's 2010... Foxhound has entered the final beta testing stage before going "GA" (generally available) as a commercial product.

See also...
What is Foxhound?
What's in the future for Foxhound?