Dear folks, it's my birthday today! You ask how old I am? Keep guessing, 'coz I won't tell ;)
Hmm...come to think of it - I haven't decided on any new 'age' resolutions...so I guess I would just continue coding.
Nothing special planned for today...being a Saturday (which is a holiday for my company), I would miss out all fun of being at office on a b'day.
In case you didn't know, it's our unofficial custom @ office that b'day guys/gals get surrounded by collegues who would first sing the b'day song, 'present' a few b'day kicks and then finally scream 'Treat'! 
Developers usually develop applications with the objective of getting the functionality
up and running as quick as possible. After the functionality is complete, they would
proceed to test their code.
Unfortunately, many developers are neither inclined to find bugs in their own code
(for, that just means more work), nor would most have that special 'testing' knack
to do so. That's where testers come in.
However, many testers I have seen weren't into hard-code development in their career; they
were just testers from the very beginnings. There are good and bad points to this.
Being completely ignorant about how an application is coded, the tester might be
able to test things that would be extremely random and 'creative' – something a
developer would have never thought.
For instance, I recently chanced to see such a tester testing an ASP.NET web form
page which had several text-input boxes, one of which had a validation criterion
of accepting (while typing) only numbers. After testing them by typing values into
text boxes directly, this guy opened up an instance of notepad, typed in several
words, copied them into the clipboard, and pasted it into the text box. The text
box happily accepted the input without validating! These are things routine developers
wouldn't think about.
However, testers who weren't developers before could miss out finding serious bugs.
For example, some time back I was involved in an ASP.NET project for a short period
of time. The project had a screen for displaying and editing information of a user,
and the user ids were passed in the query string. Obviously, a user is supposed
to view only his own information.
Now, the tester who was assigned this screen wasn't concerned about those "queer
set of strings" in the address bar. Needless to say, he missed this very obvious
but critical bug - a user could change the value passed in the query string to access
information of any other user! Sadly though, the developer who coded the screen
never thought of this bug either!
This brings us to this point – we need both non-dev 'creative' testers and the dev
testers to test applications. Skipping over one of these can result in a product
of inferior quality. We can't be sure that a developer would find bugs in his
own code, unless he has a high degree of professionalism.
In my opinion, I feel a solution like follows could help ensure that both kinds
of tests happen.
- Make the technical lead of the project test the code of his team members, for he
would (hopefully) have a greater deal of responsibility on product quality than
his subordinates.
- Assign a non-techie tester to test the application, so that he could find out the
remaining 'creative' bugs.
- And if you find the rare breed of developer/tester who can do both, hire him!
More importantly, flaws in the design and structure of the application are more
critical (in magnitudes), and will have to be caught as early as possible. However,
this will require a different kind of approach. More on this later...
In .NET 1.x, these exceptions weren't serializable - which meant we couldn't persist/transport them in a direct manner.
Thankfully, .NET 2.0 has both of them serializable
System.Data.OleDb.OleDbException: Unspecified error while calling the Connection.Open method on an Access or Excel file within ASP.NET. This is an issue you could face while opening Excel or Access files as data sources in ASP.NET using OleDb Jet.
Cause Number 1
ASP.NET/Impersonated account doesn’t have enough privileges to create the ldb file.
Resolution Give the ASP.NET user account create/write privileges to the folder where the excel/access file is placed. If you are using impersonation, give the impersonated account the said privileges.
Cause Number 2
Impersonated account doesn’t have enough privileges to create temporary files.
Description When you open excel or access files using Jet, it requires creation of temporary files. Under ASP.NET, these files will be created under the
C:\Documents and Settings\MachineName\ASPNET\Local Settings\Temp folder. By default, the ASP.NET user account is given full access to this folder. Now, when you are using impersonation, the impersonated account naturally wouldn’t have access to this folder. Consequently, the Jet engine wouldn’t be able to create the temporarily files while opening connections to excel or access files under ASP.NET. Due to this, the OleDb provider throws an exception with no specific message -
System.Data.OleDb.OleDbException: Unspecified error. Resolution Give the impersonated account full access to the above mentioned folder.
Check out the Microsoft support article
here[
^]
I just completed uploading pics from the MVP Summit held @ Singapore on April 2005 (yes...it was long overdue :( ).
Here are the MSN Spaces and .Text links to the photo albums:
So why did I add them at both locations? MSN's photo album features are really good (like uploading, slide show etc.)...but the pics look a bit odd...they seem to be rescaled with lesser quality. With .Text however, you need to struggle with uploading, live without the slide show and other cool features of MSN; yet, the pics looks great. That's why.
Happy browsing...