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
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!
Powered by ScribeFire.
Compare Windows and Web Versions
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 Webpowered by performancing firefox
Problems running with limited user accounts
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.
Labels: foxfire 6, registry
Why do my 3.0 relationships not work in 6.0 or 8.0?
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.
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)
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.
