Rakesh Rajan's blog : ASP.NET

System.Data.OleDb.OleDbException: Unspecified error

rakeshrajan — Mon, 04 Jul 2005 20:04:00 GMT

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[^]

Just posted my first ASP.NET article!

rakeshrajan — Mon, 06 Jun 2005 01:26:00 GMT

I just posted my first ever ASP.NET article :)

That too, after a significant time!

Hmm...I should write more frequently...

Data binding syntaxes

rakeshrajan — Sun, 10 Apr 2005 21:05:00 GMT

Background
DataBinder.Eval and the standard explicit casting of Container.DataItem are the two syntaxes you could use while performing data binding. Some developers are stringent on performance (they use only the standard syntax), some are concerned about maintenance (nothing but DataBinder.Eval), while some are least bothered about the syntax they use. I have seen code filled with DataBinder.Eval where the standard Container.DataItem syntax would have been a perfect fit. So I thought I would write a little bit on how to select the appropriate data binding syntax.

There are two data binding syntaxes you could employ when you use repeated value data binding:

the standard syntax with explicit casting of Container.DataItem
the DataBinder.Eval syntax

The following two expressions perform the same binding (they both bind to the 'City' column of the current data item), but uses the different syntaxes mentioned above.

<%# ((DataRowView)Container.DataItem)["City"] %>
<%# DataBinder.Eval(Container.DataItem, "City") %>

The problem with the first syntax (the standard data binding syntax) is that if the data source changes, we need to change the cast too. Say, if the data source in the above example changes to a data reader, then we need to change the syntax to:

<%# ((DbDataRecord)Container.DataItem)["City"] %>

In other words, the standard data binding syntax is 'strongly typed'.

DataBinder.Eval was provided as a helper method to simplify the standard data binding syntax. Instead of you specifying the syntax (with the data item type etc.), DataBinder.Eval figures out the syntax on its own and in addition, formats the result and returns a string.

The bad thing about DataBinder.Eval is that since it uses late-bound reflection to figure out the data types of the source specified, it comes with a performance hit.

So how do we decide which data binding syntax to use?

Use DataBinder.Eval if...

You are into control development. When you develop controls, you are not sure what kind of data source types your control is going to be bound to. Moreover, you also wouldn't like to force your clients to use a specific data source type.
You don't mind a performance hit.
You are too lazy to go to every page and change the standard syntax whenever the data source type changes :)

Use the standard syntax if...

You want to squeeze every bit of performance out of your pages.
You know what the data source type of a control is, and you are also sure that the data source type won't change
You don't mind doing a CStr or a ToString wherever required

Both approaches have their own good and bad sides. I hope the points above would help you decide on which one to select.