Friday, September 30, 2005
Wednesday, September 28, 2005
Holy smokes, Microsoft changed the certification schema again
and was about to do all the labs and get my hands on the Exam Cram book
I read that MS will be changing the certifications next month and I might need to upgrade my skills, right before getting the MCP exam. Ok, Ok, I knew this might happen, I just didn't know it would be so soon...
Here's a paragraph taken from the original article:
According to Valvano, Microsoft will follow tradition, releasing exams for SQL Server 2005 and Visual Studio 2005 about 45 days after the release of the products to the general public. Those exams, however, won't fit into the traditional MCP schema that one might be familiar with. Instead, Microsoft will introduce a new framework for certification that will pair up a credential with a skill-identifying certification based on a tiered approach consisting of the following credentials:
- Tier 1: Microsoft Certified Technology Specialist will require simply passing one to three exams based on a Microsoft technology. As products meet the end of the support lifecycle, its related exam will be retired.
- Tier 2: Microsoft Certified IT Professional or Professional Developer require a Technology Specialist certification, plus one to three more exams, based on the requirement for a particular path. This tier is tied to job role at an organization, such as Database Developer or Business Intelligence. Recertification will be required to maintain status at this level.
- Tier 3: Microsoft Certified Architect is a rigorous, board-level certification that requires recertification. Achieving Technology Specialist or IT Professional or Professional Developer certification not a prerequisite to attaining this level of certification.
Wednesday, September 21, 2005
Frustration with T-SQL 2000
The web application logs all of it errors in a sql server 2000 database, which is neat as we can review the logs and see what script produced the error, what specific query string was sent to that page, the exception it caused and the end user only sees a nice looking message of "We're sorry, please try again" kind of thing.
I've been trying to isolate a pretty random error, trying to nail down the cause. I reviewed the error log table and need to filter an nvarchar field.
My T-sql sentence looks like this:
SELECT *
FROM dbo.ErrorLog
WHERE
(datestamp = '9/19/2005') AND (error LIKE 'Object reference %')
Reviewing the help, I found there are very few wildcards and zero support for regular expressions.
So, here's my formal complain, how are we going to do decent querying without regular expressions. I know MSSQL 2005 will include the .NET Framework inside and that means it will include the Regex namespace, but, wouldn't it be more efficient to have reg exps on the T-sql level, instead of having the overload of creating objects just for using regexps?
I've been told we should avoid using the Framework on our SQL 2005 sprocs whenever we can accomplish the same task with T-SQL...
Regexps, regexps!
Monday, September 19, 2005
IE 5.2 over Mac OS bug with Localized Strings
The solution? Unknown, Microsoft is no longer developing IE browsers for Mac Operating Systems, is also no longer giving support for IE over Mac. What we are doing is detecting the browser and OS combination and rendering a disclaimer note on the page.
This post is just a curious note on a so far undocumented bug.
Here's a very useful browser detection script taken from QuirksMode.org
var detect = navigator.userAgent.toLowerCase();
var OS,browser,version,total,thestring;
if (checkIt('konqueror'))
{
browser = "Konqueror";
OS = "Linux";
}
else if (checkIt('safari')) browser = "Safari"
else if (checkIt('omniweb')) browser = "OmniWeb"
else if (checkIt('opera')) browser = "Opera"
else if (checkIt('webtv')) browser = "WebTV";
else if (checkIt('icab')) browser = "iCab"
else if (checkIt('msie')) browser = "Internet Explorer"
else if (!checkIt('compatible'))
{
browser = "Netscape Navigator"
version = detect.charAt(8);
}
else browser = "An unknown browser";
if (!version) version = detect.charAt(place + thestring.length);
if (!OS)
{
if (checkIt('linux')) OS = "Linux";
else if (checkIt('x11')) OS = "Unix";
else if (checkIt('mac')) OS = "Mac"
else if (checkIt('win')) OS = "Windows"
else OS = "an unknown operating system";
}
function checkIt(string)
{
place = detect.indexOf(string) + 1;
thestring = string;
return place;
}
Friday, September 16, 2005
Fun with Globalization, Double.Parse method and French strings
The string was converted fine for all the cultures in the application but French.
I was complete puzzled, aren't doubles the same in all cultures? Isn't mathematics the same? The Earth is round, the Pi number is the same no matter what language you speak, then why this statement will throw an "Expression cannot be evaluated" exception when the Current Thread culture is fr-FR????? Nonsense.
intUserRadius = Round(intUserRadius * Double.Parse(strRadiusUnits)
The same happened with
intUserRadius = Round(intUserRadius * CDbl(strRadiusUnits)
Both Functions failed on French, it seemed that French doubles are not the same.
Ok, the decimal separator in fr-FR is a comma and not a point, but the strRadiusUnits string is a string that is not culture biased and has a decimal point as separator.
It looks like this parsing functions were expecting a comma instead of a decimal point, so the following work around had to be applied:
intUserRadius = Round(intUserRadius * Double.Parse(strRadiusUnits, CultureInfo.InvariantCulture))
So, beware of the string parsing when you're handling Global applications.
I got these two replies from a developers list:
Mathematics is the same in all cultures, but the character-based
representations of them may not be.
English is 1.5, others are 1,5
The default behavior Microsoft decided upon was basically "you can write
lazy code to your own current culture and not have to worry about
globalization". This means that people who use 1,5 to represent one and a
half don't have to do anything to write code to parse their own cultural
representation of the value. Once you get into multiple cultures, you have
to stop being lazy and use the supplied culture-aware overloads.
In your case, you have an English-centric view of data in your database
(1.609) which just so happens to be the "invariant" culture Microsoft
decided upon in their libraries. So to parse the data you'd need to use
Double.Parse("1.609", CultureInfo.InvariantCulture)
Thanks Adam for the reply.
Double.Parse(string)
You are parsing *from* a string, and "1.609" as a string
does not match the local culture. Any and all conversions
to/from strings need to be scrutinised for culture issues.
Far better would have been to store & retrieve a double
value from the database, rather than relying on using
strings as an intermediate format.
Thanks John for that reply.
Hth,
PG
Thursday, September 08, 2005
Why there shouldn't be primary keys with business meaning...
SELECT field1, field2 from ChildTable where FKField in (Select PKfield from ParentTable where fileteringfield='value')
If the FK is a composite key, this is two fields instead of one field as FK, the statement:
SELECT field1 from ChildTable where FKField1, FKField2 in (Select PKfield1, PKfield2 from ParentTable where fileteringfield='value')
will fail.
I know someone might point out, why not using joins? Sure that would be the only solution, but you would be joining on two fields instead of one...and why consuming more resources on a nested loop for the inner join?