Why?

Answer: Different email clients handle HTML text in different ways, with some garbling the text more than others.

See also...
Help - Foxhound Options - Global Email Settings
Help - Monitor Options - Alert Email Setup

Answer:

If the Foxhound engine is started as a service it will only be able to use System DSNs, not User DSNs.

Try using the String tab of the Foxhound Menu page instead of the DSN tab.

Alternatively, you can delete each User DSN and recreate it as a System DSN.

Answer:

One possibility is that your Foxhound database is being backed up on a regular basis by a scheduled task, and that task runs the $backup_foxhound5.bat command file which automatically starts the database if it isn't already running.

Answer: This can occur normally when the target database is running on the secondary (mirror) server and failover occurs; for example:

• Foxhound is successfully gathering samples from both the primary and secondary (mirror) servers in a High Availability (HA) setup.

• The primary server fails, and the secondary (mirror) server automatically becomes the primary server as part of the failover process.

• The Foxhound sampling session that was connected to the old primary server loses its connection (because the primary server failed).

• That Foxhound sampling session automatically connects to the server which used to be the secondary (mirror) server and now is the primary server.

• The other Foxhound sampling session remains connected to the server which used to be the secondary (mirror) server and now is the primary server.

• ...which means both Foxhound sessions are connected to the same database, hence the "Duplicate Foxhound sampling sessions" message.

Foxhound Sampling Session #1... Connection string name: HA_Demo_16_Primary Connection string: SERVER=primary_demo; UID=dba; PWD=sql; HOST=Computer1:55501,Computer2:55502; DRIVER=SQL Anywhere Native; Sampling OK ... Machine: XPS ... Server: partner2_demo ... Database: demo ... Updatable primary database. Arbiter is connected. Partner is disconnected, synchronizing. Duplicate Foxhound sampling sessions. There is more than one Foxhound connection to this target database.

Foxhound Sampling Session #2... Connection string name: HA_Demo_16_Secondary Connection string: SERVER=secondary_demo; UID=dba; PWD=sql; HOST=Computer1:55501,Computer2:55502; DRIVER=SQL Anywhere Native; Sampling OK ... Machine: XPS ... Server: partner2_demo ... Database: demo ... Updatable primary database. Arbiter is connected. Partner is disconnected, synchronizing. Duplicate Foxhound sampling sessions. There is more than one Foxhound connection to this target database.

Answer: Foxhound does not actually issue Alert #1 right away, it waits for at least one minute (or whatever the Alert #1 criteria has been set to) after Foxhound is started.

Here is an example where it looks like the Alert #1 was issued right after the "Foxhound stopped" period ended. However, the timestamps show that the "Foxhound stopped" period ended at 6:53:15 AM but the Alert #1 wasn't issued until 6:55:26 AM:

6:55:39 AM 8.1s .1s / .1s 2 ... 6:55:36 AM ALL CLEAR - Alert #1: Foxhound has been unable to gather samples for 1m or longer. 6:55:31 AM 2m 16.2s .1s / .1s 2 ... 6:55:26 AM Alert #1: Foxhound has been unable to gather samples for 1m or longer. 6:53:15 AM 27.5s -- Foxhound stopped -- 6:52:47 AM 1h 6m 41s -- Foxhound stopped at --

See also...
Help - Monitor Options

Answer:

One reason may be that a database monitor session is repeatedly trying to connect to a target database that is not available. In this case the workaround is to switch to the Monitor tab of the Foxhound menu, and click on the Cancel button to stop Foxhound from repeatedly trying to connect to that database.

Another workaround is to kill the Foxhound dbsrv17.exe task and then restart Foxhound in "safe mode"; see Help - Introduction - Safe Mode Startup.

Answer:

If you have a lot of sampling sessions defined, even if they are all stopped, it takes some time for Foxhound to process them when starting up.

When this delay occurs, you may see "Foxhound was not available yet..." instead of the Foxhound Menu page.

You may also see "Preparing monitor sample sessions..." in the Foxhound database server console window for a long time before "Foxhound now accepting requests" appears.

This delay will be longest when the computer running Foxhound has just been rebooted.

You can speed up the next startup by deleting old sample sessions you no long need.

Answer:

If the situation persists, check to see if the rental period has expired in which case the entire sampling process is disabled. In this case, "Status: ...stopping" will change to "Stopped" when an Rental Renewal, Basic or Extended activation key is applied.

If that isn't the reason, and the situation persists, please report the problem.

See also...
How do I renew the Rental Edition of Foxhound 5?
How do I report unexpected errors and exceptions?

Answer:

After starting each sampling session Foxhound waits 2 seconds before starting the next one in order to prevent performance problems within Foxhound itself.

For example, if Foxhound itself is shut down and restarted, and there are 100 separate target databases for it to monitor, it will take at least 99 * 2 seconds = 3 minutes and 18 seconds for Foxhound to restart all 100 monitor sessions.

Answer:

If all of the following conditions are true

• Foxhound is set up to monitor that target database,

• the DSN or connection string used by Foxhound to connect to that database includes the AUTOSTART=YES connection parameter,

• the target database runs on the same computer as Foxhound,

then Foxhound will keep trying to connect to the target database after you have shut it down, and the AUTOSTART=YES connection parameter will cause that database to be automatically restarted.

Even if you shut Foxhound down before stopping your target database, as soon as you start Foxhound again it will automatically restart your target database.

Here are two solutions:

• Remove the AUTOSTART=YES connection parameter from the DSN or connection string, or

• tell Foxhound to stop sampling that database.

Answer: This can occur normally when the target database is running on the secondary (mirror) server in a High Availability (HA) setup and failover occurs; for example:

• Foxhound is successfully connected to the secondary (mirror) server, and the Foxhound ping process is successful.

• Foxhound displays this in the "database disposition" field...

  Read-only secondary (mirror) database. Arbiter was connected. Partner was connected, synchronized. 
  

• The primary server fails, and the secondary (mirror) server automatically becomes the primary server as part of the failover process.

• Foxhound now displays this in the "database disposition" field...

  Updatable primary database. Arbiter is connected. Partner is disconnected, synchronizing.
  

• Foxhound remains connected to the server which used to be the secondary (mirror) server and now is the primary server.

  This may be "curious" behavior on the part of SQL Anywhere but it is expected.

• Foxhound continues to gather samples, but the ping process fails because it cannot establish a new connection to a server that doesn't exist.

Machine: XPS ... Server: partner2_demo ... Database: demo ... Updatable primary database. Arbiter was connected. Partner was disconnected, synchronizing. Response... Heartbeat, Samples Interval Sample, Ping 3:23:11 PM 10s 3ms / 76ms / Failed ... Ping failed at 3:23:12 PM: SQLCODE -100, SQLSTATE 08W01, Database server not found connection_string = "SERVER=secondary_demo;UID=dba;HOST=Computer1:55501,Computer2:55502;AutoStop=NO;AutoStart=NO;ConnectionName=Foxhound-ping-7396;CPOOL=NO" ping_id = 968870, sampling_id = 119, started_at_sample_set_number = 968867, return_code = -100, diagnostic_code = 1

If you stop and restart sampling to force Foxhound to reconnect to the secondary (mirror) database, that will now fail...

Response... Heartbeat, Samples Interval Sample, Ping 3:31:23 PM 8.9s -- Database server not found -- 3:31:14 PM 8.2s -- Database server not found at -- 3:31:06 PM 89ms -- Sampling stopped -- 3:31:06 PM 9.9s -- Sampling stopped at -- 3:30:56 PM 9.9s 1ms / 34ms / Failed ...

Answer: The Foxhound database can grow very large when there are a lot of connections to the target databases, and when that sample data is maintained for a long time. All of that data must be copied from the old Foxhound database to the new one when you install a new version of Foxhound, and that process can take a long time.

See also...
How do I shrink the size of the Foxhound database?

Answer:

The Foxhound Installshield unsetup process only removes files and shortcuts that were installed by the original Foxhound Installshield setup process.

Other files which are created by the post-setup or other later processes are not removed. The foxhound5.db.ORIGINAL_COPY is an example of a file created (via the COPY command) during the post-setup process, so it isn't removed by the unsetup. However, it will be overwritten by the next post-setup process.

Answer:

The Locks Held at the database level often disagrees with the total of the Locks Held at the connection level. The values are captured at slightly different moments in time, and locks are often obtained and released at a very high rate.

Answer:

On rare occasion some of the Foxhound shortcuts may still be visible even after Unsetup Foxhound has deleted them; if you try to delete them manually via right mouse - Delete a "not found" message is displayed, and if you reboot the shortcuts will no longer be visible.

Answer:

Most Alert settings are specific to each target database, including the "Send Alert emails:" and "Email address(es) for alerts:" fields on the Monitor Options page.

If you filled in or changed the [Default Settings] on the Monitor Options page after a sampling session was created for a target database, those changes won't automatically apply to that target database, only to new target databases when sampling sessions are created for them... stopping and starting a sampling session doesn't help, the [Default Settings] are automatically applied only to new sampling sessions.

When you have a large number of target databases, it is easy to forget to fill in the Monitor Options page for all the right targets.

You can either use the Switch Display button on the Monitor Options page to go and fix the settings for the existing target database, or use the Force Default Settings On All Targets button to "publish" the [Default Settings] to all existing target databases.

Also check the Foxhound Options page for the global email settings:

• Make sure the "Enable Emails" button is checked in the Global Overrides section.

• Make sure the "SMTP Sender:" and other fields are filled in in the Global Email Settings section.

Answer:

Check to see if you have pressed the Disable Refresh button on the Monitor tab on the Foxhound Menu page.

If so, press the Refresh Display or Enable Refresh button to update the Monitor tab display.

Answer:

If you don't see your new connection strings on the String tab of the Foxhound Menu page right away after you used the Create Connection Strings button on the Monitor Options page, try using the browser refresh button to force the Foxhound Menu page to be redisplayed.

Also, if the connection strings don't appear on the on the Monitor tab of the Foxhound Menu page right away, perhaps you forgot to start them :)

Answer:

1. Make sure "Enable Schedules" is checked in the 1. Global Overrides section of the Foxhound Options or Monitor Options page. This checkbox lets you turn off all schedules in an emergency.

2. Make sure the appropriate "Enforce" checkboxes is checked on the Monitor Options page for the target database you're interested in:

• 5. Sample Schedule - Enforce the Sample Schedule

• 6. Connection Sample Schedule - Enforce the Connection Sample Schedule

• 8. Alert Email Schedule - Enforce the Alert Email Schedule

• 11. AutoDrop Schedule - Enforce the AutoDrop Schedule

3. Make sure the schedule boxes are be set to something other than all "Y"s or all "."s in order to have an effect. A schedule of all "Y"s or all "."s is the same as turning sampling on and off with no scheduled changes at all.

Note that changes to the schedules aren't retroactive. For example, if you change the Sample Schedule to turn off sampling from 5 PM to 9 AM but you didn't make the change until 8PM, sampling won't be turned off until 8 PM (the point you changed the schedule).

Answer: The target database server (and/or the computer running Foxhound) may be hopelessly overloaded; Foxhound may take longer than one minute (or whatever the threshold is for Alert #1 - Database unresponsive) to gather a sample. In that case Foxhound will issue Alert #1 while it's waiting for the sample data to be returned and then immediately issue an All Clear when it does get the data... hence the multiple Alert #1 and All Clear #1 messages.

You can deal with the "hopelessly overloaded" situation, or use the Monitor Options page to increase the threshold for Alert #1 - Database unresponsive from 1 minute to some value larger than the time it takes the Foxhound Monitor to gather a sample (the "Interval" time shown on the Monitor page).

See also...
Help - Monitor Options

Answer:

The default threshold for Alert #14 is defined as "The number of requests waiting to be processed has reached 5 or more for 10 or more recent samples."

In that definition, "10 or more recent samples" is not the same as "10 or more consecutive samples". Here's how Foxhound counts "recent samples" for Alert #14:

• Samples at or above the threshold count as +1 recent samples.

• Samples below the threshold count as -2 recent samples.

Here's why: Just because one single sample fell below 5 unscheduled requests doesn't mean the counting of "recent samples" must start over again from zero.

In the following example Alert #14 was issued after the threshold count of 5 was reached after only 3 "consecutive samples" because the number of "recent samples" was much higher:

Active Req, Max Req, Samples ... Unsch Req ... 6:12:52 AM Alert #14: The number of requests waiting to be processed has reached 5 or more for 10 or more recent samples. 6:12:51 AM ... 4 / 20 / 38 ... 6:12:41 AM ... 4 / 20 / 10 ... 6:12:31 AM ... 4 / 20 / 11 ... 6:12:21 AM ... 4 / 20 / 4 ... 6:12:11 AM ... 4 / 20 / 15 ... 6:12:01 AM ... 4 / 20 / 13 ... 6:11:51 AM ... 3 / 20 / 10 ... 6:11:41 AM ... 4 / 20 / 30 ... 6:11:31 AM ... 4 / 20 / 4 ... 6:11:21 AM ... 3 / 20 / 18 ... 6:11:11 AM ... 3 / 20 / 14 ... 6:11:01 AM ... 4 / 20 / 15 ... 6:10:51 AM ... 3 / 20 / 18 ... 6:10:41 AM ... 4 / 20 / 17 ... 6:10:31 AM ... 4 / 20 / 20 ... 6:10:21 AM ... 3 / 20 / 24 ... 6:10:11 AM ... 4 / 20 / 2 ... 6:10:01 AM ... 3 / 20 / 16 ... 6:09:51 AM ... 4 / 20 / 7 ... 6:09:41 AM ... 4 / 20 / 9 ... 6:09:31 AM ... 4 / 20 / 6 ... 6:09:21 AM ... 4 / 20 / 11 ...

Answer:

The "Interval" times on the Monitor page should be 10 seconds or close to it, and the "Sample Times" should be less than 1 second

Here is an example where Foxhound is taking longer than normal to gather samples:

Heartbeat, Sample Samples Interval Times 5:40:56 AM 14.3s .1s / 13.2s 5:40:42 AM 12.3s .1s / 11.3s 5:40:30 AM 15.9s .1s / 14.9s

Have a look at the "SPs are OK:" field in the Monitor Status Area at the top of the Monitor page.

If it is showing SPs are OK: NNN or something other than SPs are OK: YYY, try to ensure that the Foxhound's three stored procedures for gathering performance statistics are installed on the target database; see Help - Introduction - Connecting to Target Databases.

Answer: This may be due to some problem that affects the normal ability of the Foxhound Monitor to reconnect to target database(s) in order to resume sampling when Foxhound is restarted. This is not an expected situation: even if Foxhound can't connect to the target databases it shouldn't become unresponsive.

In order to get Foxhound to respond so you can figure out what's going wrong, you can suppress the automatic reconnection process by starting Foxhound in "safe mode", also known as safe startup.

Here is an example of this scenario: A Foxhound Monitor session used the SQL Anywhere 11 ODBC driver to connect to a local SQL Anywhere 8 target database server on a Windows Vista system where no SQL Anywhere 8 ODBC driver software had been installed. Not only did Foxhound become unresponsive, but restarting Foxhound didn't help until sampling was stopped by using safe-mode startup.

For more information about errors during Foxhound startup, try using one of the "debug" scripts; see Help - Introduction - Starting Foxhound - Method 2: Debug Startup.

See also...
How do I see Foxhound diagnostics, errors and exceptions?

Answer: The Foxhound installation process involves more than just an InstallShield / Windows Installer "setup" step, it includes a "post-setup" step. When you run the InstallShield / Windows Installer "uninstall" process, it only reverses the actions performed by the original "setup" step, not the "post-setup" command file...

That's why around here we call it "unsetup" instead of "uninstall".

The unsetup process uses the Microsoft Windows Installer command MsiExec.exe /X{B0FE1886-2DBE-4269-8EBD-2A3EF45C4EF5} command to reverse the actions of the original Foxhound InstallShield setup process. The MsiExec.exe /X unsetup process

• removes shortucts from Start menu,
• deletes files that were copied to the hard drive by the original setup step, and
• generally makes it possible to install Foxhound again.

The unsetup process does not affect any of the files that were moved or copied by the post-setup process. In particular, the unsetup process will not delete the Foxhound database. This fact makes it possible to upgrade an existing database by first running unsetup and then installing a new version of Foxhound.

If you want to completely remove Foxhound from your system, you have to run the unsetup process and then manually delete the Foxhound folder.

By default, Foxhound is installed in this location on Windows 10:

C:\ProgramData\RisingRoad\Foxhound5

See also...
How do I install Foxhound?
How do I install a new version of Foxhound?
How do I reinstall Foxhound?
Another version of this product is already installed.
How do I remove Foxhound from my system?

Answer:

Here is an example where scrolling may appear to be stuck on the History page; the top line shows that Foxhound had been stopped for over three days as of 9:09:20 AM on September 4:

       9:09:20 AM  3d 17h 3m 43s  -- Foxhound stopped --
Aug 31 4:05:37 PM  3.1s           -- Foxhound stopped at --

If you try to scroll to an earlier sample by one "Day »" Foxhound won't do anything because there were no samples recorded on September 3.

Try clicking on a different scroll amount (e.g., "1 sample »") or click on one of the sample lines before the gap (e.g., the "Aug 31 4:05:37 PM" line).

Answer: The bytes per row amount is based on the disk space used for table data, extension and index pages. It doesn't include free pages in the database, but it does count free space in pages allocated to this table. As such, this number is usually larger, sometimes quite a bit larger, than the average number of bytes a query might return. To avoid showing inflated numbers for very small tables, the bytes per row is only shown for tables with at least 2 data or 2 extension pages.

See also...
Help - Display Schema - The Tables List

Answer: The delivered files rroad5_sa17_bin32.dll and/or rroad5_sa17_bin64.dll may be missing from the folder containing Foxhound executables.

To confirm this, look at Foxhound Options - Display Diagnostics to see if there is a message "Unable to read ... rroad5 ...".

See also...
Unable to read ... rroad5 ...
How do I see Foxhound diagnostics, errors and exceptions?

Answer:

The CPU time % is for the server, not the database. If the server is running more than one database, the CPU time % includes the time spent by the server on all the databases.

Answer:

It is disabled when the [Default Settings] are not currently displayed.

To enable the Force Default Settings On All Targets button, use the Switch Display button to switch to the [Default Settings].

Answer:

You can only use ODBC Administrator button on the DSN tab of the Foxhound Menu if Foxhound is running on the same computer as the web browser; otherwise, the button is disabled.

This restriction is a practical one: The ODBC Administrator button starts the ODBC Administrator on the same computer as the web browser, and it only has access to DSNs located on that local computer. If Foxhound is running on some other computer on the network, it can only use DSNs located on that other computer, which makes the ODBC Administrator button on the local computer useless... and that's why it is disabled.

Workaround: Use the String tab of the Foxhound Menu to create and edit connection strings, instead of using the DSN tab. The connection strings on the String tab are available to you for editing via a web browser running on a different computer from Foxhound, and they are stored inside the Foxhound database so they are available to Foxhound for making connections to target databases.

Answer:

It is disabled when the [Default Settings] are already being displayed.

To cancel any changes you have made on the Monitor Options page, close the page without pressing any of the Save buttons.

To enable the Restore Default Settings button, use the Switch Display button to switch to a target database rather than [Default Settings].

Answer:

It is disabled when the [Default Settings] are currently displayed.

To save any changes you have made on the Monitor Options page, press one of the various Save buttons.

To enable the Save Settings As Default button, use the Switch Display button to switch to a target database rather than [Default Settings].

Answer:

The Facts & Figures section shows the file size whereas the Monitor page shows how much of that space is currently used.

Answer:

It is a design decision to not issue Alert #1 - Database unresponsive when Foxhound has never been able to connect to a target database and collect a sample.

This situation typically arises when Foxhound is attempting to connect for the first time but cannot because of some problem such as "Specified database not found".

In particular, Foxhound will not issue an Alert #1 unless it can find one of the following:

• At least one successful sample recorded earlier for this database,

• a "Sampling stopped" condition recorded earlier for this database, or

• a "Foxhound stopped" condition recorded earlier.

Answer:

The FOXHOUND5 environment variable may not be properly set by the InstallShield setup until you (a) reboot or (b) open and close Environment Variables in Control Panel. If necessary, you can reboot to put the new value into effect, or you just use Control Panel to display the environment variables which seems to have the same effect:

Start 
  - Control Panel 
    - System 
      - Advanced system settings 
        - Environment Variables... 

Start 
  - Control Panel 
    - System 
      - Advanced system settings 
        - Environment Variables... 
          - System variables 
              - select FOXHOUND5 
              - verify that it contains C:\ProgramData\RisingRoad\Foxhound5\  - or wherever Foxhound was installed
              - if not, click Edit... and fix it.

Answer:

Here are some possible explanations:

• The "after [n] day(s)" threshold should read "keep the most recent [n] days of successful samples".

  The "after [n] day(s)" calculations for the purge process are based on the most recent successful sample, not the current timestamp. That means the most recent [n] day(s) worth of successful samples will be preserved if sampling is turned off or stops for some other reason. It also means that if there are no successful samples, nothing is purged.

• Safe mode may be on.

• The rental period may have expired.

See also...
How do I renew the Rental Edition of Foxhound 5?

Answer:

Check to see if you have started Foxhound in "safe mode".

If so, shut down Foxhound, delete the startup.txt file, and start Foxhound again.

Answer: The answer depends on whether Foxhound is connecting via the DSN tab or the String tab.

If you are connecting via the DSN tab Foxhound uses AUTOSTART=NO and AutoStop=NO even if you have specified something different inside the ODBC DSN. The reason is this: In general, folks don't want Foxhound auto-starting and auto-stopping their databases, they want that functionality reserved for their applications.

In this case, you will have to start the database before trying to get Foxhound to connect to it. For example, you can use the ODBC Administrator Test Connection button, or run your application to auto-start the database, or start the engine via a command-line script (batch file).

If you are connecting via the String tab Foxhound also defaults to AUTOSTART=NO and AutoStop=NO, but you can override that with an explicit AUTOSTART=YES if you want.

See also...
Help - Foxhound Menu - The DSN Tab