When firing up my wife's new laptop the other day, I attempted to view the stats on one of my blogs hosted on blogger.com, and was greeted with a rather bizarre error:
"Possible problem with your *.gwt.xml file. The compile-time user.Agent value (ie8) differs from the run-time value (safari). Expect more errors."
This was a bizarre error, particularly because it sounded like a configuration element from the server, not a local file. So, being the nosy developer I am, I started snooping. It took a couple of hours, but I think I understand the basic problem, and can provide at least a temporary fix.
This error originates from websites built with the Google Web Toolkit, which allows for a combination of Java and Ajax to build rich web applications. It's been around for a few years now, and most people don't even see it. However, with the beta and pending release of IE9, a problem arose with certain code that detects the type of browser you use to visit a particular site. My reading leads me to believe that the code to detect your browser has been overhauled because of IE9, and that overhaul has introduced a bug. It causes a plain-vanilla IE8 browser to be interpreted incorrectly as Safari.
The real fix, if I'm correct, is for the folks at Google to fix the newly introduced error into their user-Agent handling code. Until then, and given that you make registry changes to your system ONLY at your own risk, you might be able to get away with the following:
1. Determine if the Google ChromeFrame extension is installed. Go to Tools->Manage Add Ons, and look for "ChromeFrame BHO", and ensure it is enabled.
2. If it is present, and enabled, open Registry Editor (regedit), and look for the following value:
HKEY_CURRENT_USER\Software\Google\ChromeFrame
3. If it is present, add the following DWORD value with a default of 1:
IsDefaultRenderer
4. Ensure all instances of Internet Explorer are exited, and then restart IE.
Try your site, and see if the error is gone.
Good luck!
Showing posts with label error. Show all posts
Showing posts with label error. Show all posts
Saturday, August 13, 2011
Thursday, August 13, 2009
Outer Joins, Nulls, and related evil
If you've ever written a query in a relational database language, you've probably encountered two things:
1. The concept of a left outer join
2. Nulls
The first isn't so hard to conceive, but the second causes wailing and gnashing of teeth in the minds of newbie database students and Oracle developers.
We won't go into the deep details of these monsters here, for we'll assume if you've read this far, you probably have a basic understanding of what they are. It is my duty here, however, to point out a subtle but dangerous hideousness that lay within these two when mixed in the cauldron of a query.
The basics: If you "left outer join" Table "A" with Table "B", you get all records from Table "A", and matching records from Table "B". If no records in "B" satisfy the join condition, the fields in the resultant query from table "B" are simply "null."
Suppose, for the sake of illustrating our Subtle Point of Evil, that your Table "B" has a nullable field that you need to ensure has no value, eg is null. You might be tempted to write:
That seems innocent enough, doesn't it?
But it's wrong.
Let's explore this a bit while you cogitate on the problem.
Consider the situation in which Table "B" has a record that matches on field, but BigData has a value. Because the null test is part of the join predicate, the presence of that value in that "B" record causes the predicate to fail, resulting in no matching records. When this happens, consider the result: the fields from the record in table "A" (our "left" table) will be returned, but nulls for the fields in B indicating the failure of the join predicate (no records). Therein, however. is the evil: the result set appears to show a null value for B.BigData from the joined record, when in reality BigData for this value of field is not null! This means the null in the join condition causes an improper (and misleading) result to be returned - the indication data does not exist where it clearly does.
How do we fix this problem? The solution lies in recognizing the distinction between join predicates and where clauses. Joins hook together, where's filter. In this case, putting the null test in our join predicate is really not the best solution, because it amounts to a filter, not a join.
Fortunately, the solution is relatively simple, but subtle. Applying the idea that we want to think of joins as "glue," and wheres as "filters" that take place after the join is applied (or after the glue has dried), we realize moving the test to the where is the solution. Here's our winner, as follows:
From our discussion above, we know that B has a record that matches across the field field, and as a result we know that it will be included in our left outer join result. This time, however, the where clause will inspect b.BigData for each record in our result set, and because our join condition returns the proper match, the theoretical record in "B" that contains a value in BigData for the matching field value will be eliminated, and the corret resultset returned.
Nulls and joins give more developers headaches than a lack of morning coffee. I showed this example to a DBA friend, and he was somewhat on the fence about whether the average developer would catch this subtlety. An experienced query writer shouldn't make this mistake, but a developer for whom query writing might not be a primary task could. In any event, its a critical example of where a technical subtlety could result in potentially serious consequences, and remind us all how important the "little things" are in every aspect of our jobs.
Blessings, all...
David
1. The concept of a left outer join
2. Nulls
The first isn't so hard to conceive, but the second causes wailing and gnashing of teeth in the minds of newbie database students and Oracle developers.
We won't go into the deep details of these monsters here, for we'll assume if you've read this far, you probably have a basic understanding of what they are. It is my duty here, however, to point out a subtle but dangerous hideousness that lay within these two when mixed in the cauldron of a query.
The basics: If you "left outer join" Table "A" with Table "B", you get all records from Table "A", and matching records from Table "B". If no records in "B" satisfy the join condition, the fields in the resultant query from table "B" are simply "null."
Suppose, for the sake of illustrating our Subtle Point of Evil, that your Table "B" has a nullable field that you need to ensure has no value, eg is null. You might be tempted to write:
Select *
from A
left outer join B
on a.field=b.field
and b.BigData is null
That seems innocent enough, doesn't it?
But it's wrong.
Let's explore this a bit while you cogitate on the problem.
Consider the situation in which Table "B" has a record that matches on field, but BigData has a value. Because the null test is part of the join predicate, the presence of that value in that "B" record causes the predicate to fail, resulting in no matching records. When this happens, consider the result: the fields from the record in table "A" (our "left" table) will be returned, but nulls for the fields in B indicating the failure of the join predicate (no records). Therein, however. is the evil: the result set appears to show a null value for B.BigData from the joined record, when in reality BigData for this value of field is not null! This means the null in the join condition causes an improper (and misleading) result to be returned - the indication data does not exist where it clearly does.
How do we fix this problem? The solution lies in recognizing the distinction between join predicates and where clauses. Joins hook together, where's filter. In this case, putting the null test in our join predicate is really not the best solution, because it amounts to a filter, not a join.
Fortunately, the solution is relatively simple, but subtle. Applying the idea that we want to think of joins as "glue," and wheres as "filters" that take place after the join is applied (or after the glue has dried), we realize moving the test to the where is the solution. Here's our winner, as follows:
Select *
from A
left outer join B
on a.field=b.field
where b.BigData is null
From our discussion above, we know that B has a record that matches across the field field, and as a result we know that it will be included in our left outer join result. This time, however, the where clause will inspect b.BigData for each record in our result set, and because our join condition returns the proper match, the theoretical record in "B" that contains a value in BigData for the matching field value will be eliminated, and the corret resultset returned.
Nulls and joins give more developers headaches than a lack of morning coffee. I showed this example to a DBA friend, and he was somewhat on the fence about whether the average developer would catch this subtlety. An experienced query writer shouldn't make this mistake, but a developer for whom query writing might not be a primary task could. In any event, its a critical example of where a technical subtlety could result in potentially serious consequences, and remind us all how important the "little things" are in every aspect of our jobs.
Blessings, all...
David
Subscribe to:
Posts (Atom)