See "Connection timeout:" on the Foxhound Options page.

Some other web server is already using the HTTP port, try another port number.

Without a primary key or unique constraint, some operations may be slow.

This table has more than one million rows so there is a very real danger those operations will be extremely slow; think geological time scale :)

Because there is no way to uniquely identify each row in this table, queries and database recovery operations may be slow.

This table has more than one million rows so there is a very real danger those operations will be extremely slow; think geological time scale :)

If you are connecting via the String tab, here are the likely causes:

• If you have not specified a a DSN, make sure to specify a DRIVER.
  
  
• If there is a space ahead of the DRIVER parameter, try removing it. Certain versions of SQL Anywhere have a problem with that.
  
  
• If you have specified a DSN, make sure it exists. Try using the DSN tab instead.

Here are some possibilities:

• A local target database was specified, and that database is not running.
  
  
• A local target database was specified, Foxhound is running as a service, and the ODBC DSN for the target database specified Shared memory on the ODBC Administrator Network Tab. If the local target server accepts TCP/IP communications, change the ODBC DSN to specify TCP/IP with HOST=LOCALHOST;DOBROAD=NONE on the ODBC Administrator Network Tab instead of Shared memory. Otherwise, stop the Foxhound service and restart Foxhound as a desktop process using a Start - All Programs menu item.
  
  
• A HOST= network server address was specified, and that server is not running.
  
  
• The correct HOST= network server address was specified on the Network tab, but the ENG= server name is wrong.
  
  
• The wrong HOST= network server address was specified on the Network tab.
  
  
• Caution: If you change the HOST= value, you may connect to the wrong server if a different, but working, IP address was cached in the workstation file C:\Program Files\Sybase\SQL Anywhere 9\win32\asasrv.ini. To avoid using this cache file specify "DOBROADCAST=NONE" on the Network tab; e.g.: use HOST=ip-address;DOBROADCAST=NONE to force only that address to be used.

Some other web server may already be using the HTTP port; if so, try another port number.

Use Task Manager to stop the Foxhound's process dbeng10.exe:

Task Manager - Processes - select Image Name dbeng10.exe - click on End Process Click on Retry in the "Error 1306" dialog.

Look in the target database server console log for a message like this: Cannot open dbspace 'xxx' from file 'incorrect-filespec'.

To fix the problem, ALTER the DBSPACE and then restart the engine: ALTER DBSPACE xxx RENAME 'correct-filespec';

Foxhound needs "JavaScript" or "Active scripting" to be enabled in the browser; here's how:

• Firefox 2: Tools - Options - Content - check "Enable JavaScript"
  
  
• Internet Explorer 7: Tools - Internet Options - Security - Local intranet - Custom level... - Scripting - Active scripting - check "Enable"

Sampling stopped because the Foxhound engine was not running.

Try connecting from the browser again.

You installed a new Foxhound build, and it successfully pushed the new version of this stored procedure to a target database.

You installed a new Foxhound build, and it successfully pushed the new version of this stored procedure to a target database.

You installed a new Foxhound build, and it successfully pushed the new version of this stored procedure to a target database.

If Foxhound is trying to make connection to a local SQL Anywhere 5.5 target database, make sure that "Agent - Not Specified" is selected on the Startup Options dialog box of the ODBC DSN. In particular, the registry entry for the ODBC DSN should not include an "Agent"="..." line.

Passwords may be cAsE sEnSiTiVe in your Version 10 target database.

This is an informational message only.

Foxhound shows all tables using SQL Anywhere 9 syntax even if the target database uses a different version. In particular, the CONSTRAINT keyword is used but the WITH HASH SIZE clause is not shown.

Multiple indexes on the same columns often indicate an inefficiency or error in database design. Sometimes multiple indexes are redundant, and redundant indexes may waste space in the database; they may also waste time every time a row is inserted or deleted, and every time the indexed columns are updated. Other times, multiple indexes aren't redundant, but they still might indicate a flaw in the database design.

Note: Versions 10 and later of SQL Anywhere do not create duplicate physical indexes when duplicate logical indexes are defined. However, Foxhound still warns about these duplicates because it may be a design issue. The duplication may affect performance; e.g., if one of the indexes is incorrect it may not be used to improve performance in the way it was intended. It may also affect integrity; e.g., if one of the indexes is a foreign key referring to the wrong column it may not be used to check referential integrity in the way it was intended.

Note: Versions 7 and later of SQL Anywhere automatically create a separate unique index for every PRIMARY KEY and UNIQUE column or table constraint that you define, as well as a separate non-unique index for every FOREIGN KEY constraint. There is no reason to explicitly create indexes on the same columns, and such indexes are redundant.

However, versions 5 and 6 of SQL Anywhere create a combined index for each PRIMARY KEY or UNIQUE constraint; this index "also contains the entries for all foreign keys that reference this table, whether those foreign keys appear in the same table or in a different one" (from the ASA 6 User's Guide, Chapter 25, The effect of column order in a composite index). These combined indexes can be much larger than an ordinary index on the primary key or unique constraint columns, and in those cases an explicitly created unique index on the same columns may improve performance. Such indexes are no longer needed in versions 7 and later.

The following discussion is written in terms of SQL Anywhere Version 9; i.e., separate indexes are automatically created for all primary keys, unique constraints and foreign keys.

Each list of two or more indexes is sorted by "relative importance" to help you choose which ones to keep: primary key first, then foreign key, UNIQUE constraint, UNIQUE index and finally non-unique index.

Each pair of multiple indexes should be considered separately, as follows:

• Primary key and unique constraint on the same columns: The unique constraint is redundant and should be dropped; a primary key acts as a unique constraint and is supported by a unique index. If the unique constraint is clustered, make the primary key clustered.
  
  
• Primary key and unique index on the same columns: The unique index is redundant and should be dropped. If the unique index is clustered, make the primary key clustered.
  
  
• Primary key and non-unique index on the same columns: The non-unique index is redundant and should be dropped. If the non-unique index is clustered, make the primary key clustered.
  
  
• Primary key and foreign key on the same columns: Determine why this table has the same columns in the primary key as in the parent table's primary key or unique constraint that is the target of the foreign key; there may be a design error. Otherwise, if the primary key and foreign key are both required, there's nothing that can be done about the fact the foreign key index is redundant from a performance point of view.
  
  
• Two unique constraints on the same columns: One unique constraint is redundant and should be dropped. If one of the unique constraints is clustered, drop the other one.
  
  
• Unique constraint and unique index on the same columns: The unique index is redundant and should be dropped; each unique constraint is supported by a unique index. If the unique index is clustered, make the unique constraint clustered.
  
  
• Unique constraint and non-unique index on the same columns: The non-unique index is redundant and should be dropped. If the non-unique index is clustered, make the unique constraint clustered.
  
  
• Unique constraint and foreign key on the same columns: Determine why this table has the same columns in the candidate key (unique constraint) as in the parent table's primary key or unique constraint that is the target of the foreign key; there may be a design error. Otherwise, if the unique constraint and foreign key are both required, there's nothing that can be done about the fact the foreign key index is redundant from a performance point of view.
  
  
• Two unique indexes on the same columns: One unique index is redundant and should be dropped. If one of the unique indexes is clustered, drop the other one.
  
  
• Unique index and non-unique index on the same columns: The non-unique index is redundant and should be dropped. If the non-unique index is clustered, make the unique index clustered.
  
  
• Unique index and foreign key on the same columns: Determine why this table has the same columns in the unique index as in the parent table's primary key or unique constraint that is the target of the foreign key; there may be a design error. Otherwise, if the unique index and foreign key are both required, there's nothing that can be done about the fact the foreign key index is redundant from a performance point of view.
  
  
• Two non-unique indexes on the same columns: One non-unique index is redundant and should be dropped. If one of the non-unique indexes is clustered, drop the other one.
  
  
• Non-unique index and foreign key on the same columns: The non-unique index is redundant and should be dropped. If the non-unique index is clustered, make the foreign key clustered.
  
  
• Two foreign keys on the same columns: If the same primary key or unique constraint in the same parent table is the target for both foreign keys, one of the foreign keys is redundant and should be dropped. Otherwise, determine why two different foreign key constraints on the same column are required; there may be a design error. If both foreign keys are required, there's nothing that can be done about the fact one of them is redundant from a performance point of view.

Without a primary key or unique constraint, some operations may be slow.

This table currently has fewer than 1,000 rows so there may be no performance problems, but if the table grows larger those operations may become extremely slow.

Because there is no way to uniquely identify each row in this table, queries and database recovery operations may be slow.

This table currently has fewer than 1,000 rows so there may be no performance problems, but if the table grows larger those operations may become extremely slow.

This is an informational message only.

This view may raise a syntax error if you use it in a SQL statement.

The Foxhound purge process last ran at the "Older sample purged at" date/time, and sample date/time to the left identifies the most recent sample that was deleted.

Foxhound will still work but performance may be affected, especially if there are a lot of connections to the target database.

One solution is to GRANT RESOURCE to the user id Foxhound uses to connect to the target database.

Another solution is to create the procedures yourself on the target database, with the Foxhound user id as the owner.

For more information see Foxhound Help - Introduction and Setup - Connecting to Target Databases.

Foxhound will still work but performance may be affected, especially if there are a lot of connections to the target database.

One solution is to GRANT RESOURCE to the user id Foxhound uses to connect to the target database.

Another solution is to create the procedures yourself on the target database, with the Foxhound user id as the owner.

For more information see Foxhound Help - Introduction and Setup - Connecting to Target Databases.

Foxhound will still work but performance may be affected, especially if there are a lot of connections to the target database.

One solution is to GRANT RESOURCE to the user id Foxhound uses to connect to the target database.

Another solution is to create the procedures yourself on the target database, with the Foxhound user id as the owner.

For more information see Foxhound Help - Introduction and Setup - Connecting to Target Databases.

When using the "DSN" tab to connect, the user id and password values must be specified together, either in the Foxhound "User Id:" and "Password:" fields, or inside the ODBC DSN.

A newer version of the Foxhound Monitor was previously used on this target database.

Use that version of Foxhound instead of this one, or drop the procedure from the target database so the old version of Foxhound can use its own version.

A newer version of the Foxhound Monitor was previously used on this target database.

Use that version of Foxhound instead of this one, or drop the procedure from the target database so the old version of Foxhound can use its own version.

A newer version of the Foxhound Monitor was previously used on this target database.

Use that version of Foxhound instead of this one, or drop the procedure from the target database so the old version of Foxhound can use its own version.

Use to=600;kto=600 options when starting the Foxhound engine, as in -xs http(port=80;maxsize=0;to=600;kto=600)

Your ODBC DSN may be trying to auto-start the target database on the Foxhound engine because no value has been specified the target server name. Go to the Database tab in the ODBC Configuration for your DSN and fill in the "Server name:" field with the same value as the "Database name:" field. If the "Database name:" is empty, use the file name from the "Database file:" field; e.g., if your database file is c:\path\xyz.db, put xyz in the "Server name:" field.

Samples were not recorded because you clicked Stop Sampling.

Use the ODBC Administrator link to check the ODBC DSN for a problem like this:

The "Database file:" field is filled in and "Start database automatically" is checked, but the database is already running. If your ODBC DSN specifies different "Server name" and/or "Database name" values than the ones already in use, it will try to start the same database file a second time, and that is not allowed. If that is the case, change the "Server name" and/or "Database name" values to match the ones already in use. You can leave the "Database file:" field is filled in and "Start database automatically" checked if you want, so your ODBC DSN will auto-start the database when it isn't already running.

Check ODBC DSN or connection string for a problem like one of these:

• The server is running, but the database name is wrong.
  
  
• The server is not running, and no database file is specified.
  
  
• The server starts OK, but the specified database file is not found.

Foxhound currently supports only databases created with SQL Anywhere 5.5, 6, 7, 8, 9, 10, 11 and 12.

Other versions of SQL Anywhere can be used to run the databases being displayed, but Foxhound itself requires a particular version to run.

The Foxhound engine stopped because you clicked Stop Foxhound Engine.

If the target database is using SQL Anywhere 5.5, try upgrading to 5.5.5.2787.

If the target database is using SQL Anywhere 5.5, try upgrading to 5.5.5.2787.

If the target database is using SQL Anywhere 5.5, try upgrading to 5.5.5.2787.

If the target database is using SQL Anywhere 5.5, try upgrading to 5.5.5.2787.

Start the Foxhound engine and try again.

The Foxhound engine stopped because you clicked Stop Foxhound Engine.

If the URL is http://localhost:12347/rroad_foxhound, start the Foxhound engine and try again.

The right frame is displayed using up-to-date information from the target database. This message is produced when you click on a link for a table or view that has been dropped since the link was displayed.

This database only contains system tables. You can see the system tables by checking Include system tables on the main menu.

This database monitor session can no longer be displayed because it has been stopped and all the corresponding data has been deleted.

If you want to start monitoring this database again, open a new Foxhound menu and then use the Monitor Database button on the DSN or String tab of the Foxhound menu.

In Internet Explorer, go to Tools - Internet Options... - Advanced tab - Security options.

Check "Allow active content to run in files on My Computer".

Foxhound supports up to 10 sampling sessions at one time. Try stopping one of the other sampling sessions; this one should then be able to start automatically.

Use the ODBC Administrator link to check the ODBC DSN for this or some other problem:

• The server is not running and "Start database automatically" is not checked.

Check the ODBC DSN or connection string for this or some other problem:

• The server is not running, and no database file is specified.

This is an unexpected message.

Without a primary key or unique constraint, some operations may be slow.

This table currently has more than 1,000 rows; performance may not be a problem now but if the table grows larger those operations may become extremely slow.

Because there is no way to uniquely identify each row in this table, queries and database recovery operations may be slow.

This table currently has more than 1,000 rows; performance may not be a problem now but if the table grows larger those operations may become extremely slow.