Foxhound now supports target databases that use SQL Anywhere 16, as well as target databases running in an OnDemand 1.0 cloud environment.
The new Connection History
page shows the performance of a single connection over time.
The Connection History page is available for target databases running on SQL Anywhere 9 and later.
It shows the same data as the connection section of the Sample History page,
except it shows only one connection instead of many, and multiple samples instead of only one sample per connection.
The Monitor and Sample History pages are now simpler and easier to read because all the information
about a blocked connection is now found in one place.
All except for one column, that is: the Blocked by Transaction Running Time (the Transaction Running
Time of the other connection) was removed because was easily confused with the Transaction Running Time
of the blocked connection.
The Blocked by Transaction Running Time can be determined by looking at the details for that other
connection, which can be displayed by clicking on the Blocked By: link.
2. New Features
The new Change Target Settings
page lets you set RememberLastPlan, RememberLastStatement and RequestTiming.
The new Change Target Settings popup window lets you change target server options on the fly,
to control the level of detail available for Foxhound to display: RememberLastPlan, RememberLastStatement and RequestTiming.
You can open this popup via links on the Monitor, Sample History and Monitor Options pages.
The Monitor and Sample History pages have been enhanced to display the machine or host name used for the target database,
as well as the SQL Anywhere server and database names.
These fields have been added as part of the support for OnDemand 1.0 environments where it's important to
know which target database is which when there are many hundreds spread across different servers and hosts.
The Alert email subject has been simplified and expanded:
Alert #n title - "name / machine / server / database"
The first line in the email body now looks like this:
Foxhound Alert #n went into effect for database "name(id) / machine / server / database" at yyyy-mm-dd hh:nn:ss:
The new OS User
column has been added to help identify connections: Conn #, ID, OS User, IP, Name.
Many applications use the same database user id (ID) for all connections so it's hard to tell who's doing what.
The new OS User column has been added to help with that.
The new Busy, Wait, Idle
columns have been added for each connection.
The cumulative Busy, Wait, Idle percentage columns have been added to the Monitor and Sample History pages to show how each connection has spent the time since it was established:
Busy is the percentage of time the connection was busy processing requests,
Wait is the percentage of time the connection was waiting for
atomic access to a resource,
I/O to complete
a lock to be acquired, and/or
the server to process requests.
Idle is the percentage of time the connection was neither busy nor waiting.
The Parent, Child Conns column set show the numbers of parent and child (internal) connections to target databases running on SQL Anywhere 12 or later.
Child Conns is a new column, and a separate entry has been added to the peaks row.
The new total Waiting Time
column has been added to the Foxhound Monitor.
A new Waiting Time column has been added to the Locks Held, Conns Blocked, Waiting Time column set in the sample section of the Monitor and Sample History pages.
It contains the total time all current connections were blocked or forced to wait during the previous interval.
The new Waiting Time column is calculated from the existing Waiting Time column in the connection section,
but rather than show the cumulative waiting time since the connections started, the new Waiting Time column
shows the total time spent waiting during the previous sample interval.
Waiting Time is a new column, and a separate entry has been added to the peaks row.
The new Last Plan Text
column has been added to the connection section.
The Last Plan Text line has been added to the connection section of the Monitor and Sample History display pages,
and to the new Connection History page.
The "Favorable? xxx" field on the Monitor and Sample History pages shows whether or not the target server is gathering extra diagnostic data that Foxhound can display.
The "xxx" string is made up of Y, N and/or - characters, where - means "unknown". The three characters correspond to these target server settings:
RememberLastPlan, RememberLastStatement and RequestTiming.
The "Favorable?" field is also a link that lets you open the new Change Target Settings popup window.
You can now specify Purge after [xx] day(s)
instead of being limited to 1 day, 1 week, 1 month or 1 year.
The Purge section of the Foxhound Options page now gives you complete freedom in setting the thresholds for deleting data.
Purge all sample data enabled: [x] after [xx] day(s)
Purge uninteresting connection data enabled: [x] after [xx] day(s)
The Monitor and Sample History page now display the Purge field to let you know how soon your data's going to be deleted.
CPU Time calculations
have been improved for connections using intra-query parallelism.
The CPU Time is no longer displayed as zero for a connection making heavy use of intra-query parallelism.
When a connection makes use of the intra-query parallelism feature, it spawns a number of internal child connections which do most of the work;
e.g., one INT: EXCHANGE child connection for each available processor.
SQL Anywhere tends to report the total CPU time used by all the child connections as the ApproximateCPUTime value for each child connection in use,
and almost none for the parent connection. This inflates the amount of CPU time used by each child connection without reporting any CPU usage
by the parent connection.
In an attempt to make sense of this behavior, Foxhound now calculates the average non-zero ApproximateCPUTime for the child connections
and reports it as as the CPU time for the parent connection.
The inflated values reported by SQL Anywhere for each child connection are still shown by Foxhound; only the parent connection CPU time is adjusted.
One consequence of this improvement is that AutoDrop #5 CPU Usage now works on parent connections using intra-query parallelism whereas before it did not.
Note that the AutoDrop process is never performed on a child connection or any other internal connection that isn't directly associated with a client application.
The separate Req, Commits and Bytes In/Out columns have been gathered into the new connection-level
Volume... Req, Commits, Bytes columns.
The new Connection Id String
can be used to uniquely identify connections in adhoc queries; e.g., '1-1-20140504073924-692'.
A new emergency patch process is built in to Foxhound for fixing bugs without running a full upgrade.
An "Emergency Patch" process has been built into Foxhound whereby SQL patch scripts may be
provided in the future and automatically applied to the Foxhound database at startup time.
Alert #30. Database read-only. The target database has changed from accepting updates to read-only processing.
Alert #31. Database updatable. The target database has changed from read-only processing to accepting updates.
Alert #32. Rollback log usage. The total rollback log space used by all connections has been 1G or larger for 10 or more recent samples.
Alert #33. Uncommitted operations. The total number of uncommitted operations for all connections has reached 1,000,000 or more during 10 or more recent samples.
Alert #34. Long uncommitted. The number of uncommitted operations has reached 10 or more while the transaction running time has reached 1m or more for at least one connection.
Alert #12 HA mode change has been removed and replaced by Alert #30 and #31 for the following reasons:
An Alert #12 was issued for non-HA databases when they are restarted with dbsrv16 -r for read-only operations,
an Alert #12 all-clear never appeared for a non-HA database, and
an Alert #12 appeared exactly once for a non-HA database when it changed from updatable to read-only.
For a new installation of Foxhound 3, the five new Alerts are all enabled by default.
For an upgrade from an existing installation of Foxhound 2 or earlier, the new Alerts are disabled
on the Monitor Options page for all existing target databases (to avoid surprises) as well as the "Default Settings",
but they are enabled in the "Factory Settings" and "Extreme Settings".
After an upgrade
if you want to enable the new Alerts for an existing target database, you will have to use the Monitor Options page to set that up, and
if you want to enable the new Alerts by default for new target databases, you will have to use the Monitor Options page to modify the "Default Settings".
The new DB File and Used
columns have been added to the Foxhound Monitor.
Foxhound now keeps track of the amount of disk space allocated to the SYSTEM DBSPACE (the DB File column) and the percentage of that space used to store data (the Used column).
The new Hide Details and Show Details
buttons let you reduce scrolling on the Sample History and Connection History pages.
Buttons have been added to the connection section of the Sample History page as well as the Connection History page
to hide and show the following lines for each connection:
AutoDrop Result:
Blocked By:
Block Reason:
Locked Row Query:
Last Statement:
Last Plan Text:
The new Show More and Show Less
buttons let you expand and contract the Last Statement and Last Plan Text connection data.
Buttons have been added to the Last Statement and Last Plan Text connection-level fields to Show More and Show Less of the data:
The display starts off in "space saving" mode:
Last Statement: Show More select "COUNT_BIG"() from "SYSCOLUMN" as "A" cross join "SYSCOLUMN" as "B" cross join "...
Last Plan Text: Show More ( Plan ( SingleRowGroupBy ( Exchange [ 8 ] ( SingleRowGroupBy ( Nested...
When you Show More all the data is displayed:
Last Statement: Show Less
select "COUNT_BIG"()
from "SYSCOLUMN" as "A"
cross join "SYSCOLUMN" as "B"
cross join "SYSCOLUMN" as "C"
Last Plan Text: Show Less
( Plan
( SingleRowGroupBy
( Exchange [ 8 ]
( SingleRowGroupBy
( NestedLoopsJoin
( NestedLoopsJoin
( ParallelTableScan ( ISYSTABCOL col ) )
( TableScan ( ISYSTABCOL col ) )
)
( TableScan ( ISYSTABCOL col ) )
)
)
)
)
)
Duplicate Foxhound sampling sessions. There is more than one Foxhound connection to this target database.
This can happen when two different Foxhound connection strings are created pointing to the same target database,
or a ODBC DSN is used as well as a Foxhound connection string. This is almost always a mistake, and it can lead to multiple Alert email
messages when the duplicate sampling sessions all detect the same condition; e.g., Alert #1 Database unresponsive.
The Foxhound option to show the Help frame
is turned back on when Foxhound is upgraded, as a reminder that new Help content is available.
Descriptive text has been added to all menu items on the
Monitor Options page.
The Peaks since
timestamp has radically abbreviated to reduce horizontal scrolling.
There's no more "Can't open Message window log file" message when starting Foxhound.
All the desktop shortcuts that start the Foxhound database have been modified to run the dbping.exe utility
before running dbsrv16.exe. If the dbping utility determines that that the Foxhound database is already running,
it doesn't bother running dbsrv16 and skips straight to launching Foxhound in the browser... not only is
the whole process much faster, it eliminates the annoying error message "Can't open Message window log file".
The default connection string for starting the Adhoc Schema database has been
renamed to "Foxhound 3 Adhoc Schema - autostart and connect".
You can select this connection string and click on the Display Schema button to see
all the views and tables that are available for adhoc reporting.
The name has been changed to include "Foxhound 3" to differentiate this
database from earlier versions of Foxhound.
If the current copy of Foxhound was upgraded from Foxhound version 2, the previous
Adhoc Schema connection string was renamed to "old Foxhound 2 Adhoc Schema - autostart and connect"
during the upgrade process.
The handling of the diagnostic text files produced during the Foxhound Post Setup process has been improved.
The Extended Edition of Foxhound no longer limits the number of separate copies of the Foxhound database
that may be created and started using separate instances of SQL Anywhere on the same local network.
This eliminates the previous limit of 1,000 target databases that may be monitored (10 copies of Foxhound x 100 target databases per copy).
Note: Here's what the End User License Agreement has to say...
In the case of the Extended Edition, an unlimited number of copies of the Foxhound database may be created and started using separate instances of SQL Anywhere on the same local network, with the requirement that a separate Extended Edition registration key be purchased for each multiple of 10 copies of Foxhound started.
Some Help topics previously found only in the
Foxhound FAQ have been moved to the Help.
In particular, all links from the Help pages to the FAQ pages have been
eliminated by "bringing home" those topics to the Help.
The Foxhound FAQ exists in one location only (the web at Foxhound 3.0 FAQ),
while the Help exists in three locations:
in the Foxhound database for display in the Foxhound Help frame,
as a separate set of local HTML files for display via All Programs - Foxhound 3 - Help, and
The Cumulative CPU Time and Total Waits columns have been removed from connection-level displays.
These numbers proved to be of little use so they were removed
to make room for other numbers.
However, the property values on which they
were based are still available for adhoc reporting.
The Client Requests, Time columns have been removed from connection-level displays.
The Client Requests column (based on the RequestsReceived property) has been removed from the
connection section of the Monitor and Sample History pages in order to reduce confusion with
the server Req column, and the Time column (based on the ReqTimeActive property) has been removed
because it is not directly related to client requests.
Both property values are still available for adhoc reporting using the sample_connection view, and
the ReqTimeActive property is now used in the calculation of the Busy portion of the new Busy, Wait, Idle columns.
The Total, Current Prepares and Rollbacks columns have been removed from connection-level displays.
These numbers proved to be of little use so they were removed
to make room for other numbers.
However, the property values on which they
were based are still available for adhoc reporting.
The Bytes In / Out columns have been removed from connection-level displays and summarized in
Volume... Req, Commits, Bytes.
Alert #11 was formerly described as HA failover - The high availability target database server has switched over to [server2].
It is now described as ServerName change - The real server name has changed to [server2], possibly because of an HA failover or OnDemand move.
The reason for this change is that it is possible for a target database to be shut down on purpose and
restarted with a different server name without High Availability being involved or a failover occurring.
For example, when a database is running in a volatile OnDemand cloud environment it is quite likely that
it may be moved from one server to another.
The alert description has been changed to stick to the facts, that PROPERTY ( 'ServerName' ) has changed
which may or may not be the result of an HA failover or an OnDemand database move to a different server.
The Waiting Req column has been renamed to
Unsch Req
to reduce confusion with SQL Anywhere documentation.
The Monitor and Sample History pages now show the title "Unsch Req" instead of "Waiting Req" for the columns based on the UnschReq property.
This has been done to reduce confusion between this and other properties which use the word "waiting" in their descriptions...
and to reflect the fact that "unscheduled requests" is common parlance when talking about this property.
The data remains unchanged, only the titles are affected.
Previously, the sort order of the connections section on the Monitor page could be changed
by clicking anywhere on the Last Statement line.
That behavior has now changed so that you must click the "Last Statement" title text
to change the sort order. Clicking on the Last Statement data value has no effect.
The security rules
are different for connecting to SQL Anywhere 16 target databases.
The new role-based security model introduced by SQL Anywhere 16 affects how Foxhound connects to those databases.
For example, the Foxhound connection to a SQL Anywhere 16 target database must use a user id with the MONITOR
system privilege in order to gather information about all the connections to that database.
Without the MONITOR privilege, Foxhound will only be able to display information about its own connection.
The dbsrv16 -ufd restart
option has been added to the desktop shortcuts to keep Foxhound running.
Foxhound is no longer being extensively tested on Windows XP or IE8.
The Rollbacks column has been removed from database-level displays.
This number proved to be of little use so it was removed
to make room for other numbers.
However, the property value on which it
was based is still available for adhoc reporting.
The Throughput... Commits
column has been rounded so rates like 0.099/s are displayed as 0.1/s, because the extra precision was not helpful.
5. Bug Fixes
Support for Snapshot Isolation
has been added, thus eliminating the fatal "Cannot convert 'Snapshot' to a decimal" error.
Previously Foxhound expected the Isolation Level to be a numeric value.
This error has now been fixed.
The "Column '@alert11_actual_current_ServerName' not found" error has been fixed.
After an Alert #11 HA failover (now Servername changed) was issued, an attempt to use the Monitor Options
page resulted in the error message "Column '@alert11_actual_current_ServerName' not found".
When sampling was started for a database running in an OnDemand cloud environment
an invalid Alert #9 was immediately issued: "Arbiter unreachable. The high availability
target database has become disconnected from the arbiter server."
This error has now been fixed.
The ALTER MATERIALIZED VIEW statement has been moved after CREATE INDEX on the
Display Schema page.
Previously an ALTER MATERIALIZED VIEW IMMEDIATE REFRESH statement would be generated ahead of a CREATE UNIQUE INDEX statement,
which is the wrong order for execution.
The email status is no longer displayed as "Email sent, status unknown." before the attempt to send an email is actually made.
The popup tips for several
Alert and
AutoDrop criteria
fields on the Monitor Options page have been changed to "Percent, 1 to 100".
The minimum input value for the AutoDrop #3 Long transaction
duration field on the Monitor Options pages has been changed to 1.0s.
Bad input values entered on the Monitor Options page for integer
Alert and
AutoDrop criteria
fields are now silently changed to the minimum allowed values.
The Foxhound Options - Purge Run
report no longer displays 2 as the number of Orphan/Old Sample Set Rows Deleted when no change is reported in the total number of rows.
The Start Foxhound via Chrome shortcut no longer has trouble finding Chrome.
The No Transaction Log curiosity message
is no longer displayed for read-only databases.
An error message is displayed instead of suppressing the sample when Foxhound
can't call sa_locks()
to diagnose a blocked connection.
The handling of invalid SQL Anywhere property values coming from target databases has been improved.
Heartbeat durations
are no longer rounded upwards; instead, values between .001s and 0.099s are changed to 0.1s to distinguish them from 0s.
Foxhound no longer tries to AutoDrop
the same connection more than once.
A dropped connection may keep running for a while as SQL Anywhere rolls back
its work even though the client application has been disconnected.
For that reason Foxhound will not try to AutoDrop a connection more than once.
The CPOOL=NO connection parameter has been added to the connection string Foxhound uses to
connect to target databases.
This does not affect target databases running on SQL Anywhere 11 or earlier, but it does help prevent problems
when sampling is stopped and restarted on target databases running on SQL Anywhere 12 and later.
Previously Foxhound was unable to read the startup.txt file when started as a service.
This error has now been fixed.
Safe Mode startup
now marks all timed out sampling sessions as no longer timed out, just stopped.
Safe Mode startup is supposed to stop all sampling sessions in such a way the can only be restarted manually.
Previously Foxhound did not clear the timed out status of a stopped sampling session when Foxhound was started in Safe Mode.
That meant when Foxhound was restarted in non-Safe Mode it would automatically restart the timed out sampling session
when the timeout retry period passed, thus defeating one of the reasons for using Safe Mode startup in the first place.
The same three global checkboxes (Enable Emails, Enable Schedules and Enable Autodrop) can be updated
by the user in two different places: the Global Overrides sections of the Foxhound Options and Monitor Options pages.
Previously, switching back and forth (e.g., saving a change on one page and then clicking Save on the other page)
could result in the wrong checkbox value being saved and/or displayed.
Schedules may be used
to control when samples
are recorded
No
No
Yes
Schedules may be used
to control when Alert
emails are sent
No
No
Yes
The AutoDrop feature may
be used to automatically
drop errant connections
No
No
Yes
Maximum number of
connections to each
target database
100 *
100 *
No limit
Maximum number of physical
CPUs used for each target
database on a SQL Anywhere
Version 10, 11, 12, 16 server
1 **
1 **
No limit
Target database may run on a
SQL Anywhere 11.0.1 or later
Standard or Advanced Edition
server
No ***
No ***
Yes
Maximum number of target
databases which may be
monitored at the same time
by a single copy of Foxhound
10
10
100
Maximum number of different
server names which may be
used when starting separate
instances of Foxhound ****
1 ****
1 ****
Unlimited ****
* This limit on connections applies to all versions and editions of SQL Anywhere target databases and servers.
The actual limit is 101 connections when you count the connection from Foxhound itself. Internal connections
(e.g., connections made by events and web services) are counted in the total.
** This limit on physical CPUs does not apply to SQL Anywhere version 5.5, 6, 7, 8 or 9 target databases and servers.
Also, it applies to the number of physical processors as given by the NumPhysicalProcessorsUsed server property,
not the number of logical processors shown by "Using n CPUs" value in the Foxhound Database Monitor.
For example, a single Intel Pentium 4 processor counts as 1 physical processor even
though the separate HyperThreading units may show up as "Using 2 CPUs". Similarly, a single Intel Core2 Quad
processor also counts as only 1 physical processor even though it may show up as "Using 4 CPUs".
*** This restriction on SQL Anywhere editions does not apply to SQL Anywhere target databases and servers earlier than version 11.0.1,
which is when SQL Anywhere introduced the notion of different editions.
**** The Rental and Basic Editions allow only one instance of Foxhound
to be started on the same local network, and the SQL Anywhere server name must be "foxhound3".
The Extended Edition allows an unlimited number of Foxhound instances to be started on the same local network,
with no restrictions on the SQL Anywhere server names; however, the License Agreement requires that a
separate Extended Edition registration key be purchased for each multiple of 10 instances started.
Question: What are the Foxhound system requirements?
Answer:
1. Windows - Foxhound works with target databases running on other operating systems but the Foxhound engine itself only runs on Windows, and has been tested on Microsoft Windows 7.
2. ODBC - Foxhound itself uses ODBC to connect to your target databases. You don't necessarily need ODBC installed on the servers running your target databases, and you can specify DSN-less connections for Foxhound by using the "String" tab on the main menu page.
3. Chrome, Firefox, IE - The Foxhound client has been tested with the latest browser versions, currently Google Chrome 34, Firefox 28 and Internet Explorer 11.
4. JavaScript - Foxhound needs "JavaScript" or "Active scripting" to be enabled in your browser.
5. SQL Anywhere versions 5.5, 6, 7, 8, 9, 10, 11, 12, 16 and OnDemand 1.0 for target databases - If you have any target databases running on SQL Anywhere 5.5 you may have to upgrade them to 5.5.05.2787 for Foxhound to work properly with them.
6. SQL Anywhere 16.0.0.1915 or later for Foxhound - Foxhound works with target databases using 5.5 to 16 of SQL Anywhere but the Foxhound engine itself needs the 32-bit or 64-bit non-authenticated version of SQL Anywhere 16.0.0.1915 or later to run.
7. SQLANY16 - The delivered *.bat files expect that the SQLANY16 environment variable points to SQL Anywhere 16. If that is not the case you may have to modify the *.bat files. Here is the default setting on Windows XP, Vista and Windows 7:
SET SQLANY16=C:\Program Files\SQL Anywhere 16
8. FOXHOUND3 - The delivered *.bat files expect that the FOXHOUND3 environment variable will be created by the Foxhound installation (which will happen by default). If that is not the case you may have to modify the *.bat files. Here is the default setting for Windows XP:
SET FOXHOUND3=C:\Documents and Settings\All Users\Application Data\RisingRoad\Foxhound3\
and for Windows Vista and Windows 7 it is this:
SET FOXHOUND3=C:\ProgramData\RisingRoad\Foxhound3\
9. Disk space - When re-installing or upgrading Foxhound, 60% or more extra disk space may be required during the post-setup process. The "60% or more" figure applies to the amount of disk space occupied by the existing Foxhound installation, not the total used disk space on the drive.
Question: What are the differences among all the activation keys?
Answer:
An Activation Key (also known as a Registration Key) is a code that lets you use a copy of Foxhound that you have already installed.
Activation Keys are available for purchase here, and the Foxhound Activation page will tell you which kind of key you need... or you can look use the following table:
If ...
Then ...
With a ...
You have just installed a fresh copy of Version 3,
without upgrading from an existing copy of Version 2
A 30-day Rental Key is a code that may be used to activate Foxhound Version 3 as a Rental Edition copy after
installing a fresh copy of Version 3 or
upgrading an existing copy of Foxhound 1 or 2.
A 30-day Rental Key may also be used to extend or renew the rental period for an existing installation of the
Rental Edition for an additional or subsequent 30-day period. A different Rental Key is required
for each 30-day period; see the Renew or Upgrade Foxhound button on the About page.
A Basic Upgrade Key is a code that may be used to activate Foxhound Version 3 as a Basic Edition copy after upgrading an existing copy of Foxhound 1 or 2.
A Extended Upgrade Key is a code that may be used to activate Foxhound Version 3 as an Extended Edition copy after upgrading an existing copy of Foxhound 1 or 2.
Question: What is the Foxhound End-User License Agreement (EULA)?
Answer: RisingRoad - 3QC Inc. License Terms
Foxhound Version 3
By using the software, you accept the following terms. IF YOU DO NOT ACCEPT THEM, DO NOT USE THE SOFTWARE.
1. No-Nonsense License Agreement
The Foxhound software is protected by United States and Canadian copyright law and international copyright treaty provisions. Therefore, you must treat Foxhound just like a book, except that you may copy it onto a computer to be used and you may make archival copies of Foxhound for the sole purpose of backing-up our software and your data and protecting your investment from loss.
By saying "just like a book," RisingRoad means, for example, that one copy of Foxhound may be executed on any number of computers, and may be freely moved from one computer to another, so long as there is no possibility of it being executed on one computer while it's being executed on another.
By saying "one copy of Foxhound", RisingRoad means a copy of the Foxhound software that has been activated by the application of one single unique registration key obtained from RisingRoad.
Just like one copy of a book can't be read by two different people in two different places at the same time, neither can one copy of Foxhound be executed on two different computers at the same time. (Unless, of course, this License Agreement has been violated.)
2. Use on a Network and the Internet
In the case of the Rental and Basic Editions, one copy of Foxhound may be executed on a computer attached to a local area network and/or the internet, with multiple users accessing the single Foxhound database from browsers running on different computers. The "just like a book" analogy begins to weaken at this point, but it still applies if you think of more than one person reading the same book over someone else's shoulder... it's still one copy of the book, and one copy of Foxhound executing.
In the case of the Extended Edition, an unlimited number of copies of the Foxhound database may be created and started using separate instances of SQL Anywhere on the same local network, with the requirement that a separate Extended Edition registration key be purchased for each multiple of 10 copies of Foxhound started.
3. Further Explanation of Copyright Law and the Scope of This License Statement
You may not download or transmit your copy of Foxhound electronically (either by direct connection or telecommunication transmission) for the purpose of executing it on multiple computers at the same time.
You may transfer all of your rights to use your copy of Foxhound to another person, provided that you transfer to that person (or destroy) all of the software and documentation provided in this package, together with all copies, tangible or intangible, including copies in RAM or installed on a disk, as well as all back-up copies. Remember, once you transfer your copy of Foxhound, it may only be executed on the single computer to which it is transferred and, of course, only in accordance with copyright law and international treaty provisions.
Except as stated in this paragraph, you may not otherwise transfer, rent, lease, sub-license, time-share, or lend the Foxhound software or documentation. Your use of Foxhound is limited to acts that are essential steps in the use of Foxhound on your computer as described in the documentation. You may not otherwise modify, alter, adapt, merge, decompile or reverse-engineer Foxhound, and you may not remove or obscure RisingRoad copyright notices.
6. Disclaimer of Warranty
The software is licensed "as is". You bear the risk of using it. RisingRoad gives no express warranties, guarantees or conditions. RisingRoad excludes the implied warranties of merchantability, fitness for a particular purpose and non-infringement.
Question: What is the upgrade policy for installing new builds of Foxhound?
Answer: At present, you can install a new build of Foxhound on top of an old one, and your data will be copied and upgraded.
In the future, limitations may be applied to the installation of new builds; e.g., the end of the
"Free Upgrade" period. These limitations
are not yet fully defined, but they will take the form of requiring you to provide a new
registration key to activate the new build.
Question: What happens when a copy of Foxhound expires?
Answer: Adhoc reporting will still be available after your installed Rental copy of Foxhound expires;
that satisfies the Foxhound promise that you always have access to data that belongs to you.
However, other features will be disabled, among them the Monitor Database, Display Schema and Alert features.
You can renew or extend your Rental copy at any time by
purchasing a new Rental Key and then entering
it on the Foxhound Activation page which will appear when you click on Monitor Database or Display Schema.
Question: What environment variables are used by Foxhound?
Answer:
FOXHOUND3 is very important. It is set by the Foxhound InstallShield setup program to contain the drive and path of the folder where Foxhound is installed. It is then used in most of the Windows command files that are executed by the Foxhound shortcuts. For example, the "Start - Foxhound3 - Start Foxhound via Chrome" executes the $start_foxhound3_chrome.bat file which contains the command CD /D "%FOXHOUND3%".
Normally you do not have to enter or change the FOXHOUND3 environment variable, but if you do, here's how:
Start
- Control Panel
- System
- Advanced system settings
- Environment Variables...
FOXHOUND3BIN is optional and rarely used. You can set it to Bin32 if you want to start Foxhound using the 32-bit version of SQL Anywhere 16 even if the 64-bit version is available. Values other than Bin32 have no effect. The default action (if FOXHOUND3BIN is not set to Bin32) is to start Foxhound using the 64-bit version of SQL Anywhere if it is installed, otherwise use the 32-bit version.
No automatic process sets or changes the FOXHOUND3BIN environment variable, it's all up to you:
Start
- Control Panel
- System
- Advanced system settings
- Environment Variables...
FOXHOUND3UPGRADE is optional and rarely used. If it is set, it is used as the initial value for
the FOXHOUND3UPGRADE setting in the post-setup process the next time you reinstall or upgrade Foxhound.
The post-setup process will prompt you to provide a different value if one is desired:
Post-Setup Process for Foxhound Version 3.0
*** Checking for a post-setup path parameter...
*** A post-setup path parameter was provided...
C:\ProgramData\RisingRoad\Foxhound3\
*******************************************************************
*** Foxhound 3.0.4380
***
*** Here's where Foxhound is being installed:
*** C:\ProgramData\RisingRoad\Foxhound3\
***
*** Starting the Foxhound 3.0.4380 post-setup process...
*** Creating foxhound3.db.3.0.4380.ORIGINAL_COPY...
*** Checking for an existing Foxhound3 installation...
*** ...yes, there is an existing Foxhound3 installation.
*** Checking if the existing data should be upgraded...
*** ...yes, the existing Foxhound3 data should be upgraded.
******************************************************************
*** PLEASE READ THIS, AND CONFIRM OR CHANGE **********************
******************************************************************
***
*** "FOXHOUND3UPGRADE" specifies how much data is to be upgraded.
***
*** If you want to CHANGE the setting, type in a new value...
*** ALL - upgrade all the data
*** OPTIONS - no samples, just the Foxhound options
*** yyyymmdd - options plus samples since yyyymmdd
*** nnn - options plus last nnn days of samples
*** NOTHING - don't upgrade any data
*** and press Enter to continue.
***
*** If you LIKE the current setting...
*** FOXHOUND3UPGRADE=ALL which means upgrade all the data
*** just press Enter.
******************************************************************
Current FOXHOUND3UPGRADE=ALL
New FOXHOUND3UPGRADE=
The default action (if FOXHOUND3UPGRADE is not set to any value) is to use the the value ALL as the initial value, which you can change as shown above;
see How do the different FOXHOUND3UPGRADE values work?
No automatic process sets or changes the FOXHOUND3UPGRADE environment variable, it's all up to you:
Start
- Control Panel
- System
- Advanced system settings
- Environment Variables...
Question: What does the connection-level "Transaction Running Time" tell me?
Answer: A long Transaction Running Time means the connection hasn't performed a COMMIT or ROLLBACK for
a long time since starting the current database transaction.
Note that each connection can only
have one database transaction in progress at any given point in time; there is no such thing
as "nested transactions", and if an application wants to run two different database transactions
at the same time it must use two different database connections.
If the Locks Held number is larger than zero, it means other connections may be prevented from
updating (and possibly even reading) rows this connection has locked; if that actually happens,
this connection's Conn # will show up in the Blocked by Conn # for the other connections.
If the Uncommitted number is larger than Locks Held, it may be that this connection is repeatedly
updating the same rows without committing the changes.
Question: What HTTP port should I use for Foxhound?
Answer: By default Foxhound uses HTTP port 80, but you can change that.
Port 4950 is officially registered to the
"Sybase Server Monitor" which is the SQL Anywhere Monitor that ships in the box with SQL Anywhere.
If you're not already running the SQL Anywhere Monitor on that port, consider using 4950 for Foxhound.
Alternatively, consider using one of the "Dynamic and/or Private Ports" in the range 49152 through 65535.
Question: What is the foxhound3.db ... .ORIGINAL_COPY file?
Answer: [
It is a copy of the foxhound3.db file as delivered; i.e., before anything was copied from the old Foxhound database including the activation status.
It is created in foxhound3\setup folder by the $post_setup.bat command file after the InstallShield setup runs but before the post-setup data upgrade process runs.
There are three "release defining" features in Foxhound Version 2:
AutoDrop and Schedules are available in the Extended Edition,
and Jumping Through History is available in all editions.
The AutoDrop process is available in the Extended Edition of Foxhound Version 2.
AutoDrop works like Alerts; with AutoDrop you specify the conditions which will cause Foxhound to automatically drop a connection:
AutoDrop #1 - Blocking others - Automatically drop each connection that has been blocking [5] or more other connections for [10] or more recent samples.
AutoDrop #2 - Blocked by other - Automatically drop each connection that has been blocked by another connection for [10] or more recent samples.
AutoDrop #3 - Long transaction - Automatically drop each connection with a transaction that has been running for [10m] or longer.
AutoDrop #4 - Temp file usage - Automatically drop each connection that uses [512M] or more of temporary file space for [10] or more recent samples.
AutoDrop #5 - CPU usage - Automatically drop each connection that uses [25]% or more of approximate CPU time for [10] or more recent samples.
AutoDrop #6 - Locks - Automatically drop each connection that has [1,000,000] or more locks for [10] or more recent samples.
Like Alerts, AutoDrop notices appear on the Monitor and History pages and they can be sent by email.
Unlike Alerts, connections that have been autodropped are highlighted in the current connections section of the Monitor and History pages:
Also, the Do-Not-AutoDrop lists let you specify which important user ids and connection names are to be excluded from the AutoDrop process.
The AutoDrop process is available for target databases running on SQL Anywhere Version 9 and above.
The Schedules feature is available in the Extended Edition of Foxhound Version 2.
Schedules let you tell the Foxhound Database Monitor when to turn various processes on and off.
Schedules are entered as one string for each day and one character for each 15-minute period with Ys and dots representing "on" and "off":
The Sample Schedule controls everything: it specifies when the entire Foxhound Monitor process is turned on and off.
For example, you might turn sampling off during regularly-scheduled outages or periods of complete inactivity.
When the Monitor is running, three other schedules can be used to fine-tune Foxhound processing:
The Connection Sample Schedule turns the gathering of connection-level sample detail on and off.
For example, you might be interested in database availability on a 24-hour basis, but not detailed
information about all the connections in a large pool during the overnight hours. Depending on the number
of connections and the schedule settings, the Connection Sample Schedule can dramatically reduce the growth
of the Foxhound database.
The Alert Email Schedule turns Alert emails on and off. For example, Alerts may only be important enough for
emails to be sent during certain hours of the day and/or days of the week.
The AutoDrop Schedule turns the AutoDrop process on and off. For example, off-peak periods may be set aside
for processes that might cause blocking and other problems if they were run during peak periods.
The Jumping Through History feature is available in all editions of Foxhound Version 2.
The new Go to: jump on the History menu lets you scroll the display directly to a date/time to see what was going on in your database back then. You don't have to be exact when entering the date/time, Foxhound will scroll to the nearest recorded sample.
After doing a direct Go to: jump, you can change the value to get closer, or use the relative menu items to scroll up and down by 1 sample, or 100 samples, or an hour, a day, a week.
The new up and down Message jumps let you skip over all the intervening samples to reach the previous or next Alert message, AutoDrop Notice or "Database stopped" message, or any of the other special actions or unusual circumstances encountered during the monitoring process.
The list of target databases on the Monitor tab of the Foxhound Menu page has been redesigned to reduce
the amount of horizontal and vertical scrolling required when you are monitoring a lot of databases.
At the same time, the full text of any error messages is now shown in the "Status" column, with wrapping enabled,
rather than truncating the text.
The columns on the Monitor and History pages have been rearranged to highlight the Latency and Throughput numbers:
The separate Bytes In and Bytes Out numbers are still shown at the connection level, but they are aggregated at the
database level as one of the Throughput numbers.
The four columns which identify each connection have been rearranged to put the connection number first: Conn # / User / IP / Name
Also, for target databases running on SQL Anywhere version 12 and later, "INT:" internal connection
numbers are sorted by their parent connection numbers.
Here's an example showing how two "INT: Exchange" connections are used
to implement intra-query parallelism:
Alert messages include the email status on the Monitor and History displays, and on the Active Alerts section of Foxhound Menu Monitor Tab.
Also, the adhoc view rroad_alert_union now includes the email_status column.
Email sent OK.
Email failed with return code xxx.
Email not sent because emails were disabled.
Email not sent because of the Alert Email Schedule.
Email sent, status unknown.
The initial sort order when you first click on the 'Last Statement:' title text in the current connection list
in the Monitor and History pages has been changed from ASC to DESC so non-empty values appear at the top of the list.
When there are a lot of connections showing on the Monitor or History pages, the column titles
"Last Statement" and "AutoDropped" might not appear on screen so there's nothing to click on if
you want to sort those values to the top. This has been fixed by adding clickable text to the
connection section heading: "Click here to sort on: Last Statement or AutoDrop message."
The Monitor and History pages now display this tip at the top of the list of current connections: "Click on a column title to sort the connections ..."
The "[Default Options]" title is color highlighted on the Monitor Options page to help prevent the
common error of making changes to the default settings rather than the options for a specific target database.
The following buttons on the Monitor Options page now automatically save any changes you have made to fields on the
screen before performing the button's primary action. Previously, you had to remember to click on one of the other "Save" buttons first.
Save Settings As Default
Save the currently displayed settings for "DSN: xxx", then copy and save them into the [Default Settings].
Force Default Settings on All Targets
Save the currently displayed [Default Settings], then copy and save them onto all other target databases.
The connection-level CPU time percentage used by the Alert #27 processing has been changed to be the percentage
of overall CPU time available, rather than the percentage of clock on the wall time. The new technique has also
been used in the new AutoDrop #5 processing.
Alert #27 Connection CPU: The approximate CPU time has been [x]% or higher for at least one connection during [y] or more recent samples.
AutoDrop #5 CPU usage: Automatically drop each connection that uses [x]% or more of approximate CPU time for [y] or more samples.
This change affects target servers using multiple CPUs. For example, if SQL Anywhere was using 8 processors, and
one connection used 8 seconds of CPU time in a 10-second interval, that would be
8 seconds / 10 seconds) / (8 processors in total) * 100 = 10% of the total available CPU time
Previously 80% was the figure used when processing Alert #27.
The Display Schema - Options page now shows the full set of target database options in the lower section of the display.
This will make it easier to copy-and-paste all the option settings for documentation and comparison purposes.
Previously, only the options currently containing the original default values were shown in the lower section.
Improved error checking has been added to the "Start Foxhound via..." shortcuts to diagnose problems with
the FOXHOUND3 and SQLANY12 environment variables and the SQL Anywhere 16 installation.
A "Refresh Display" button has been added to the Diagnostics section of the Foxhound Options page. This is more
convenient than the browser refresh button which sometimes prompts for confirmation, and then scrolls back to the top.
All the new kinds of registration keys available with Version 2 made a new design necessary
for the Foxhound Activation page.
Gone are the detailed "Step 1, Step 2, Step 3" instructions,
replaced by a simple "pick this key and press that button" process
with "What is ... ?" links to help you pick the right kind of key.
...and most of the time, if you're upgrading from Version 1.0 or 1.1,
Foxhound tells you exactly which kind of key you need.
Timeout exceptions are very common and usually useless, so they have been replaced by an additional message to the console.
Previously, Foxhound would record an exception that looked like this:
1184 2012-07-07 11:36:39.163 Full Build 4162a 1000000009 202b1(202eh1) Connection timeout for target DSN ddd12
after 15.4s (timeout threshold is 15.0s; see Foxhound Options) - 1000004860
while SQL Anywhere would produce a message on the Foxhound server console that looked like this:
I. 07/07 11:36:39. User "DBA" dropped event connection 1000004860 ("rroad_monitor_sample_loop")
The console message from SQL Anywhere can't be suppressed, and it can be confusing because it looks like an error message.
Now, two messages appear on the console, with the one coming from Foxhound helping to explain why SQL Anywhere produced the other message:
I. 07/07 11:36:39. Connection 1000004860 dropped by Foxhound because it failed to connect to target DSN ddd12
after 15.4s (timeout threshold is 15.0s; see Foxhound Options)
I. 07/07 11:36:39. User "DBA" dropped event connection 1000004860 ("rroad_monitor_sample_loop")
CREATE VIEW autodrop_candidate AS SELECT * FROM rroad_autodrop_candidate;
CREATE VIEW autodropped_connection AS SELECT * FROM rroad_autodropped_connection;
CREATE VIEW message_locator AS SELECT * FROM rroad_message_locator;
CREATE VIEW schedule AS SELECT * FROM rroad_schedule;
CREATE VIEW schedule_day_entry AS SELECT * FROM rroad_schedule_day_entry;
CREATE VIEW schedule_period_entry AS SELECT * FROM rroad_schedule_period_entry;
New columns...
rroad_group_1_property_pivot.CPU_count INTEGER NULL,
rroad_group_1_property_pivot.autodropped_connection_count INTEGER NOT NULL DEFAULT 0,
rroad_group_2_property_pivot.autodrop_attempt_count INTEGER NOT NULL DEFAULT 0,
rroad_group_2_property_pivot.autodrop_reason LONG VARCHAR NOT NULL DEFAULT '',
rroad_group_2_property_pivot.autodrop_result LONG VARCHAR NOT NULL DEFAULT '',
rroad_group_2_property_pivot.ParentConnection BIGINT NULL, -- '- - - - - -- -- 12'
rroad_group_2_property_pivot.interval_CPU_percent DECIMAL ( 30, 1 ) NOT NULL DEFAULT 0, -- old rows will have zero values
More examples have been added to the adhoc FAQ "How do I run adhoc queries on the Foxhound database?"
http://www.risingroad.com/foxhound/faq/FAQ-How-do-I-run-adhoc-queries-on-the-Foxhound-database.html
Recent blocked connections.
Long-running queries.
Latency and throughput history plus 100-sample moving averages.
Two important Foxhound database primary key values, sampling_id and sample_set_number, are now displayed on the Monitor and History pages;
for example, "[4,1796] Recent Sample" and "[4,1796] Samples".
Now it's easier to write adhoc queries that display the same rows that are showing up on the Monitor and History pages.
The sample_set_number values can also be used in the Go to: field on the History menu.
The Active I/Os column has been removed from the Monitor and History pages because the SQL Anywhere CurrIO statistic
on which it is based is unreliable for all target servers up to and including version 12.0.1.
When CurrIO becomes reliable the Active I/Os column may be restored.
Fix: Monitor sampling status shown as "...stopping" long after sampling was stopped.
The sampling status is now promptly shown as "Stopped" on the Monitor page after the Stop Sampling button is pressed,
and on the Monitor tab of the Foxhound Menu page after the Stop link is clicked.
Fix: Emails failing because the email address was empty.
Emails are no longer sent if you leave the Email address(es) for Alerts and AutoDrop Notices: field empty
on the Monitor Options page, thus reducing the number of "Email Failure" messages.
Fix: Incorrect "Running for", "Started at xxx Foxhound time" and overall "CPU Time xx% av" display values.
An error was fixed whereby the difference between the target database server system clock time and the Foxhound
system clock time was sometimes ignored (assumed to be zero) when the Foxhound time was earlier (smaller in value).
For example, if the Foxhound time was set to Pacific Standard time (smaller) but the target database server was using
Eastern Standard time (larger), Foxhound would incorrectly assume that all the times reported by the target database
server were using Pacific Standard time.
The error affected the following three values displayed on the Monitor and History pages in the Most Recent Sample
and Top Sample display areas:
Server running time "Running for" and "Was running for" may show a value that's too low; e.g., 0s.
Server start time "Started at xxx Foxhound time" may show a value that is too high, possibly even in the future.
Overall CPU average "xx% av" may show a value that's too high; e.g., 100%.
The underlying problem was that zero was stored in the rroad_group_1_property_pivot.datediff_msec_between_target_and_local
column, which also affected the adhoc query view column sample_detail.datediff_msec_between_target_and_local.
That column value was used for calculating the three display values listed above.
For example, the server start time recorded in the sample_detail.StartTime column
would be treated as if it was three hours later than it actually was; i.e., Foxhound would assume the
target server had been running for three hours less than it actually had, causing the overall average CPU %
to be shown as higher than it should have been. In an extreme case, the "Started at ... Foxhound time" might
show a value in the future (later than the time the corresponding sample was recorded).
Other calculations were not affected because they were based on a different column
rroad_sample_set.datediff_msec_between_target_and_local which contained a correct (negative) value.
This error has been fixed for new samples by allowing negative values to be stored in the
datediff_msec_between_target_and_local columns.
However, samples recorded before upgrading to the fixed version of Foxhound may still contain incorrect zero values.
Fix: Incorrect Time Connected 0s.
An error was fixed whereby the difference between the target database server system clock time and the Foxhound
system clock time ignored (assumed to be zero) when calculating the connection-level time connected.
This error caused incorrect values (e.g., 0s) to be stored in the rroad_group_2_property_pivot.time_connected column and the
corresponding adhoc reporting view column sample_connection.time_connected.
This error has been fixed for new samples by storing the correct values in the time_connected columns.
However, samples recorded before upgrading to the fixed version of Foxhound may still contain incorrect values.
Fix: Bogus Alert #1 when the clock lurches forward.
An error was fixed whereby an Alert #1 (Database unresponsive) was incorrectly issued, followed soon thereafter by an All Clear,
when the system clock on the computer running Foxhound was set forward.
This error has been fixed by checking to see if the current time has changed by 30 seconds or more between successive passes
through the main Foxhound 5-second monitor timing loop, and if it has, skipping the check for Alert #1 until the next sample
is taken.
Fix: Bogus Alert #1 after pressing Start Sampling.
An error was fixed whereby an Alert #1 (Database unresponsive) was incorrectly issued, followed soon thereafter by an All Clear,
immediately after the "Start Sampling" button was pressed after resolving an earlier problem involving a Foxhound limitation;
e.g., "Foxhound Extended edition is required for more than 100 target database connections"
This error has been fixed by correctly recognizing that the earlier problem caused sampling to be stopped, and that the time
spent while sampling was stopped should not be counted towards the threshold for issuing an Alert #1.
Fix: Meaningless message "Multiprogramming level ... different from default 20".
An error was fixed whereby Foxhound would incorrectly display a Database Curiosity message when the multiprogramming
level was different from 20 even though automatic tuning of the multiprogramming level was in effect.
For example, "Multiprogramming level -gn 12 -- different from default 20" should not have been displayed because the
server was continuously changing the value.
This error has been fixed by not checking the multiprogramming level against the default when automatic tuning
of the multiprogramming level is in effect.
Fix: Count of index lookups incorrectly shown as a per-second rate.
A display formatting error was fixed on the Monitor and History pages whereby the number of index lookups was incorrectly shown as
a rate in the Most Recent Sample / Top Sample section rather than a count. For example, it was shown as +24,810/s instead of +24,810.
This error has been fixed by dropping the "/s" from the display.
Fix: Peak Cache Satisfaction "-".
A rounding error was fixed whereby a value of 99.5% and higher would not be recorded in the rroad_peaks.peak_CacheSatisfaction
column. Consequently, drops in the cache satisfaction to as low as 99.5% would appear as "-" on the "Peaks since" line on the
Monitor and History pages.
Note: For cache satisfaction, lower values are regarded as "peaks" rather than higher values.
This error also affected the adhoc reporting view column peaks.peak_CacheSatisfaction.
This error has been fixed by recognizing two decimal digits of precision when checking to see if a new cache satisfaction value
is different from 100% before storing it in the rroad_peaks table and the peaks view.
However, the current value stored in rroad_peaks.peak_CacheSatisfaction will not be affected by samples recorded before upgrading
to the fixed version of Foxhound; i.e., old rows will not be reprocessed, and the "Peaks since" row may continue to hold an incorrect
value until a new sample causes rroad_peaks.peak_CacheSatisfaction to be changed.
Fix: Bogus Temp Space = 32,768G
An error was fixed whereby Foxhound did not take any corrective action when it received invalid CONNECTION_PROPERTY ( 'TempFilePages' )
values such as 4,294,967,281 and 4,294,967,287. These values caused Foxhound to calculate incorrect Temp Space values like 32,768G.
This error has been fixed for new samples by aggressively limiting values received from the target database for this
property value to the range 0 to 4,290,000,000 and setting values outside that range to zero.
However, samples recorded before upgrading to the fixed version of Foxhound may still contain the incorrect value,
and the "Peaks since" row may continue to hold an incorrect value until the "Reset Peaks" button is pressed.
Fix: Bogus LockCount = 4,294,967,295
An error was fixed whereby Foxhound did not take any corrective action when it received the invalid DB_PROPERTY ( 'LockCount' )
value of 4,294,967,295 from the target database. This error caused the incorrect value of 4,294,967,295 to be stored
in the rroad_group_1_property_pivot.LockCount column and the corresponding adhoc reporting view column
of sample_detail.LockCount, as well as the "Peaks since" columns rroad_peaks.peak_LockCount and peaks.peak_LockCount.
This error has been fixed for new samples by aggressively limiting values received from the target database for this
and some other property values to the range 0 to 100,000,000 and setting values outside that range to zero.
However, samples recorded before upgrading to the fixed version of Foxhound may still contain the incorrect value,
and the "Peaks since" row may continue to hold an incorrect value until the "Reset Peaks" button is pressed.
Fix: Bogus Transaction Running Time = 41,170d 15h 13m 40s
An error was fixed whereby an empty value in the connection-level TransactionStartTime property was changed to 1900-01-01
and subsequently treated as a valid value rather "unknown", thus causing a monstrously large Transaction Running Time to be displayed.
This error, and a similar one involving the LastReqTime property, have been fixed so zero is displayed instead of the bogus values.
Fix: Value 46116860613593576000 out of range for destination.
An error was fixed whereby Foxhound did not take any corrective action when it received the invalid PROPERTY ( 'ProcessCPU' )
value of 46,116,860,613,593,576 seconds from the target database. This in turn caused a runtime error "Value 46116860613593576000
out of range for destination" when Foxhound attempted to multiply the value by 1000 to convert seconds to milliseconds.
This error has been fixed for new samples by aggressively limiting values received from the target database for this
and some other property values to the range 0 to 10,000,000,000,000,000 and setting values outside that range to zero.
However, samples recorded before upgrading to the fixed version of Foxhound may still contain the incorrect value,
and the "Peaks since" row may continue to hold an incorrect value until the "Reset Peaks" button is pressed.
In the case of this particular message, one workaround is to restart the target database to stop it from
reporting the bad value.
Fix: Error message "Column 'b' in table 'cp' cannot be NULL"
An error was fixed whereby the Foxhound Monitor would not be able to gather connection-level sample data when
the target database had the ALLOW_NULLS_BY_DEFAULT option set to 'OFF'.
This has now been fixed by explicitly specifying the NULL option on NULLable columns in a LOCAL TEMPORARY table
inside the rroad_connection_properties procedure that is created on the target database by Foxhound.
Fix: No uninteresting connections deleted.
An error was fixed whereby the uninteresting connection purge process stopped deleting
any rows if it fell behind the old sample purge process.
Fix: Redundant "Sampling stopped" messages.
An error was fixed whereby the Monitor process displayed unnecessary "Sampling stopped" messages
immediately after Foxhound was restarted.
Fix: Out-of-order messages.
Errors were fixed whereby messages appeared out of order in the Monitor and History pages.
In once case a "Database server not found at" message would appear between a pair of "Foxhound stopped at"
and "Foxhound stopped" messages, rather than after the "Foxhound stopped" message.
In another case, a successful sample would appear between a pair of "-- Database server not found at --"
and "-- Database server not found --" pair of messages, rather than after the "-- Database server not found --" message.
Fix: Some engine and database-level properties added together; e.g., CacheHits and CacheRead.
An error was fixed whereby certain properties that are now available at both the engine and server level were
being added together. With previous versions of SQL Anywhere, these properties were available at either the
engine or database levels but not both, so it was OK to add them together, but that is no longer the case.
This error has fixed by ensuring that only one of the two properties is used depending on the version of the target database server.