SSRS Error: Report Preview displays Access to the path ‘…\bin\Debug\Report.rdl’ is denied

While working on Reporting Services at a client site I came across this error when trying to preview a report in BIDS:

The report preview failed because the report could not be built. Read the errors, warnings and messages in the Error List window for specific build failures.

An error was raised in the Error List window below with the following message:

Access to the path ‘C:\Users\Jose\Documents\Visual Studio 2008\Projects\Report Project\bin\Debug\Report.rdl’ is denied

The root cause why this happens is unclear to me, but it seems that the Debug folder’s permissions get changed to Read Only for no apparent reason as can be seen on the screenshot below:

The workaround is to uncheck the Read-only attribute checkbox for the entire Debug folder or simply delete the Debug folder. BIDS will recreate this folder when you click on the Preview tab. If I come up with the root cause of this issue I will update this post.

The development environment is:
– VMWare virtual machine
– Windows Server 2008-R2 64-bit
– SQL Server Reporting Services 2008-R2 64-bit

Advertisement

SSIS errors: Bulk Load failed. Cannot obtain the required interface (“IID_IColumnsInfo”) from OLE DB provider “BULK” for linked server “(null)

When working with the Bulk Insert Task in SSIS 2008 you may get the following error:

 The complete error message is:

[Bulk Insert Task] Error: An error occurred with the following error message: “Cannot obtain the required interface (“IID_IColumnsInfo”) from OLE DB provider “BULK” for linked server “(null)”.The bulk load failed. The column is too long in the data file for row 1, column 1. Verify that the field terminator and row terminator are specified correctly.”

This error description can make you jump through hoops trying to figure out why is it detecting an error with the OLE DB provider or why does SSIS thinks you are trying to execute this operation on a linked server?

The real issue here has nothing to do with the first  sentence in the error description. Sentence 4 gives you the actual error:

Verify that the field terminator and row terminator are specified correctly.

You may be experiencing this error due to one or more of the following 3 reasons:

1) You may be specifying a wrong CommonDelimiter for your source file.
For example, You may be trying to do a Bulk Insert operation from a Comma Separated Value (CSV) file but did not change the CommonDelimiter property to Comma {,}. When you drag in the Bulk Insert Task the CommonDelimiter property default value is Tab.

2) You may be specifying a wrong RowDelimiter for your source file.
For example, you may be trying to do a Bulk Insert operation from a Comma Separated Value (CSV) file whose row delimiter character is different than the RowDelimiter property default value of {CR}{LF}. In some cases, you may receive a file with a very long stream of text with no Carriage Return (\r)  & Line Feed (\n) characters, commonly denoted as {CR}{LF} in between rows. These hidden {CR}{LF} row delimiter characters are placed on a text file each time you hit the ENTER key on your keyboard denoting the end of a row and beginning of the next row. You may read a little more about the Carriage Return and Line Feed characters in Pinal Dave’s blog: http://blog.sqlauthority.com/2009/07/01/sql-server-difference-between-line-feed-n-and-carriage-return-r-t-sql-new-line-char/

As seen on the image below, there are two properties,  CommonDelimiter and RowDelimiter, that you need to make sure  you specify the correct values for depending on your input or source file format:

.
3) You may be using a format file with an incorrect or invalid format defined.
Format files can be non-xml, commonly with an *.fmt extension or for SQL Server 2005 and later only you can also use xml format files. For more information about format files read MSDN Books on Line http://msdn.microsoft.com/en-us/library/ms191516.aspx

If you are using a format file make sure you are pointing to the right format file or that the format defined in your format file is correct. (Notice that the Format property value changes from Specify to Use File):

Lessons from my first week on Twitter.

I finally gave in to the peer pressure of social media and started tweeting and following fellow twiterers in the SQL/BI arena. The first set of questions that popped-up on my head when I made the decision to start my Twitter account were:

1. What am I going to tweet about?
2. Who will care about what I got to say?
3. Will following too many people cause an information overload?
4. Should I limit my tweets to SQL/BI only matters?
5. Will I be lost with all the lingo and abbreviations as in SMS texting?
6. Will I become addicted once again to something non-productive?
7. If I have survived life so far without Twitter, why do I need it now?
8. If I complain about not having enough time balancing work, family and professional development, how can I justify twittering?

Although,  haven’t been able to answer all of these questions, I decided to bite the bullet and get on Twitter. The closing case to become part of the Twitter gang was  made by Jorge Segarra @SQLChicken during a SQL Server R2 / Sharepoint 2010 presentation during the April 5th Tampa Bay SQL BI User Group meeting. Jorge’s statement about being a “legitimate business and professional tool for DBA’s” was heard by my boss as well, who I had invited to attend this particular meeting. Now I can justify my tweetering and blogging at work. Yey!

My next challenge was to justify my twittering at home. Of course, I wear the pants at home but…it is my wife who choses which ones should I wear, when and where. Her resistance was as expected and she just made me realize that I have become what I have always criticized her young sister about…a texting junkie! OK, so less twittering at home I concede. See what I talk about deciding when and where? She just knows how to keep the family harmony.

Eighty (80) tweets later within a week, tweeting  as @sqljoe , I have learned a couple of things:

1. Twitter feels much like those old IRC chats in  which you can filter messages by sender and topic (#channels).
2. Twitter is a great way to get in touch with respected SQL/BI experts such as seasoned DBAs, developers, authors and folks from Microsoft.
3. Interesting to learn what other DBA’s are doing in their day to day tasks, challenges and their approach, as well as learning about the technologies they play with at their jobs.
4. Twitterers and bloggers are an important part of technology marketing strategies to get the word out quickly about new products and features with minimum effort and cost, other than fine wine and limos (#sqlr2 Microsoft tweetup).
5. There are SQL chefs, midnighters, chickens, sheeps, chicks, bucks,  knights, doctors, m-a-chanics, soldiers, runners and of course regular joes and green handed masters.
6. SQL Twitterers use the word Pimpin a lot.
7. Body disposal services can be contracted through Twitter.
8. SQL experts have hair feuds as well.
9. Margaritas make you enjoy progress bars way too much.
10. DBAs do have lives and are a good source of recommendations for places to eat.

 Among other things,I think my first week on Twitter was with lack of better terms:  interestingly fun, cool and informative.