Foxfire! Support Notes

This blog has moved

2010-05-01T05:29:00.001-04:00

This blog is now located at http://foxfiresupport.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://foxfiresupport.blogspot.com/feeds/posts/default.

New Support Forums Now Open

2007-03-30T14:37:00.001-04:00

At long last, we've finally re-opened our

Support Forums on a new site, using DotNetNukem among other tools.

While we will always respond back through email, we've found that the junk email that comes in on a publicly known or common email address makes it very easy for things to slip betweeen the cracks so register on the forum and post your questions for the very latest information and support on Foxfire!

Compare Windows and Web Versions

2007-02-22T08:53:00.001-05:00

We just posted a preliminary comparison chart of our Web and Windows versions of Foxfire! 8.0. As you'll see, we've tried to maintain 100% feature for feature with the notable exception being access to the Administration tools. That's because with the Web version, you also receive a Foxfire! 8.0 Designing Administrator license.

Feature Comparison between Foxfire Windows and Web

Problems running with limited user accounts

2007-01-05T14:20:00.000-05:00

Anyone who has ever tried to deploy the Foxfire! Query and Report Writer version 6.0 on Windows XP or Terminal Server with security has likely seen this problem before. When you first start up Foxfire!, it displays a message that says Cannot Activate Bar or it may have a problem even just starting up.

Why do you get that?

ActiveBar checks for its licensing by looking in the registry in HKEY_CLASSES_ROOT\Licenses. In Windows 2003 Terminal Server and updated versions of XP, access to this key was limited to power users and administrators (I'm not sure why since this is only the license access portion of the registry but I'm sure someone can explain it to me). Since a regular user doesn't have access to this, the message appears and confuses users.

You can still run and design reports but it's still very annoying.

How Do You Solve It?
I want thank Windows Server MVP Vera Noest for this solution - I was amazed at how easy it really was.

1. Log in as Administrator.
2. Start REGEDIT (Choose Run from the Start menu and enter REGEDIT)
3. Find the key HKEY_CLASSES_ROOT\Licenses.
4. Right-click on the key and choose Permissions.
5. Set the permissions for Users to Full Control. (I'm not sure why Read is selected but Write is not but Full Control was all that was available on my end - if you can just set it to Read then you may be able to get by with this).
6. Close the Registry.
7. Re-login as a regular user.

The problem should now be solved.

Why do my 3.0 relationships not work in 6.0 or 8.0?

2006-11-09T17:22:00.000-05:00

We recently had a Foxfire! customer who was working on upgrading their 3.0 installs to version 8.0.

Unfortunately, many of the relationships that were defined in 3.0 wouldn't return the same results in 8.0 or they would report an error. It was a real mystery until I looked at how the relationships were defined.

In 3.0 (and earlier), all relationships were handled as an inner join so it never really mattered which table was listed as being the primary table or how many possible joins you had. Customers could have Invoices and then Line Items could have Invoices and Foxfire! 3.0 would make it all work.

In 6.0 and 8.0, with Outer Join support, it wouldn't be too difficult with only three tables but relationships were also defined by their "level", a term which really meant where they appeared in the tree. For example, if you had Customers with Invoices and Line Items with Invoices, your Join Tree might actually list the Invoices table twice. When Foxfire! 6.0 comes to build a relationship, it would focus on the level to identify which join to build the main relationship. In worst case scenarios, it would never pull in the relationship between Line Items and Invoices properly.

How do you fix this? By going into the Relationship Editor and reversing the relationship in question.

A good rule of thumb is that a table should only ever be listed ONCE in the Relationship tree. If it's listed more than once, you might find yourself with a problem. It's fairly easy to change - but if you are upgrading from 3.0, keep this in mind.

Note: We'll be updating the way relationships are handled in 8.1 to allow you to easily define "lookup" tables so Foxfire! won't consider them as part of key relationships.

Converting DateTime to Date Fields

2006-09-29T12:19:00.000-04:00

Many databases do not support a separate Date format from DateTime. SQL Server is one of them - you can't have just a "date" field persay; it ends up being a date/time field.

But when you're putting these fields onto a report, you don't want to show the hour and minutes - you just want to see the date.

With Foxfire!, you can do this by using the TTOD() function in the Layout Expression field. The Report Expression on the main page is passed directly to the SQL Server but the Layout expression field is used on the output.

We've done up a screencast that shows how to do this, using the SQL Server Pubs database.

Check it out here!

Outer Join Blues (or how to get the results you want)

2006-09-28T16:49:00.000-04:00

One of the issues that confuse many Foxfire! report designers is how to handle Outer Joins along with filters.

The classic example (using the Cars database) is I want to see all of my sales people along with any of their Ford sales.

The typical approach would be to build the report showing Salesperson Name, Cars Stock #, Cars Color and Cars Model.
Set the Outer Join to show you All Salespeople including those who don't have any matching cars.

But then if you add a filter to this that says Cars Make Is Like Ford, it immediately negates the Outer Join.

Why? Because you said you only wanted to see Ford Cars.

How do you get around this? By using NULL!

Add an OR to the Filter and add the condition:
Cars Make Is Null

This would make your filter read Cars Make Is Like Ford OR Cars Make Is Null.

When you run this, you will see ALL of your salespeople, not just the ones with Ford - but the only Cars information you'll see will be Fords.

Now this gets a bit trickier when you have multiple filter conditions but it's still doable. Let's say you also want to add an additional condition of sales people who have started since 2000.

So now your condition would be:
Sales Start Date Is After 1/1/2000 (and)
Cars Make Is Like Ford
OR
Cars Make Is Null.

Right?

Not quite. You need to wrap your Cars filters with Parentheses so they read:

Sales Start Date Is After 1/1/2000 (and)
(
Cars Make Is Like Ford
OR
Cars Make Is Null
)

Thankfully, in Foxfire! 8.0, you can highlight all of the conditions and just click one button to wrap them with the parentheses.

Why Can't I Create a Cross-tab on a numeric field?

2006-06-30T12:42:00.000-04:00

One of our partners approached me with a troubling question. Their application table made us of a numeric field for the Major Version # field. When they wanted to break this information into a cross-tab report, the Major Version # field did not show up in the list of available fields for the cross-tab column axis, where they wanted to put it.

The reason is based on Foxfire!'s initial assumptions when it sets up the database.

In the data dictionary, you will see that Major Ver is NOT defined as allowing an X-Tab Axis. As a result, you cannot create a cross-tab with it.

If you check this option, you can.

This is caused by the incorrect setup of your data dictionary. Was Majorver set up to do subtotals? It would be by default (because it is numeric).

Likewise, Foxfire! assumes that numeric fields would be used for summary reports - this assumption was made years ago. When a developer sets up a a database and wants a numeric field to be used as an actual content field (such as an attribute like MajorVer is used), then it should be set up differently.

In a future version, when we go through a better analysis of the data (to allow for smarter joins, etc), this may be something we want to look at but in the meantime, just go to the Data Dictionary and set it to allow for X-Tab axis and you should be able to create a cross-tab report using this field as a column or row value.

If you CANNOT set it for X-Tab axis, make sure there is a SORT expression. You must have one to create a cross-tab.

Why Can't I Filter Aggregate Fields in the List or Between

2006-06-20T11:17:00.000-04:00

So here's a scenario: you're running Foxfire! and decide to build a summary report that shows Count of Records. You're interested in seeing records where you have between 10 and 20 items.

You use the BETWEEN filter, right?

Unfortunately, no. This will give you an error in FoxFire!. Instead use the Greater than and then Less than values.

This is a carry over from Foxfire! 1.02 that we'll be fixing soon.

But I wanted to make sure it was noted.

Technically the reason is because In the List and Betweens work best with character values or dates.

Why do I have a @ in the Filter clause?

2006-06-15T13:45:00.000-04:00

If you look at the Filter tab for a Data Item, you may wonder why you see a @ in the Input Mask field - especially since the Inputmask Property in FoxPro doesn't use the @ symbol anymore.

This is a carry-over from an older DOS version of FoxFire!.

The Setup Wizard used to think like this:
If there was a index tag for a given field and it was based on UPPER(field_name), it would automatically populate the Input Mask field with a @!.

This has been changed in Foxfire! 8.0 to update the Format field instead.

FF6 : ActiveBar Evaluation Message

2006-03-28T16:18:00.000-05:00

Anyone who has ever tried to deploy the Foxfire! Query and Report Writer version 6.0 on Windows XP or Terminal Server with security has likely seen this problem before. When you first start up Foxfire!, it displays a message that says Thank you for evaluating ActiveBar by Data Dynamics.

Why do you get that?

ActiveBar checks for its licensing by looking in the registry in HKEY_CLASSES_ROOT\Licenses. In Windows 2003 Terminal Server and updated versions of XP, access to this key was limited to power users and administrators (I'm not sure why since this is only the license access portion of the registry but I'm sure someone can explain it to me). Since a regular user doesn't have access to this, the message appears and confuses users.

You can still run and design reports but it's still very annoying.

How Do You Solve It?
I want thank Windows Server MVP Vera Noest for this solution - I was amazed at how easy it really was.

1. Log in as Administrator.
2. Start REGEDIT (Choose Run from the Start menu and enter REGEDIT)
3. Find the key HKEY_CLASSES_ROOT\Licenses.
4. Right-click on the key and choose Permissions.
5. Set the permissions for Users to Full Control. (I'm not sure why Read is selected but Write is not but Full Control was all that was available on my end - if you can just set it to Read then you may be able to get by with this).
6. Close the Registry.
7. Re-login as a regular user.

The problem should now be solved.

Invalid Report Errors

2006-03-28T16:13:00.000-05:00

Every now and then, I've noticed some reports with the command Report file xxx is invalid.

The problem is usually specific to a report or installation. It also does not occur on all reports.

Why not?

A: The report layout in question has been corrupted or is having some problems.

Solution: Copy over a new report template layout. The default Foxfire! install is FFRPTHD3.FRX but you can also decide to use the supplementary templates such as FFSHADED and just copy it on top and rename it.

This should clear up this problem.