Showing posts with label reading. Show all posts
Showing posts with label reading. Show all posts

Wednesday, March 28, 2012

Having problems reading a record

I have a strongly typed dataset. I'm trying to read a record. I have the following

Dim ResourceAdapter As New ResourcesTableAdapters.ResourcesTableAdapter
Dim dF As Data.DataTable = ResourceAdapter.GetDataByResourceID(sID)
Dim RecResource As Resources.ResourcesRow

strBody = "The following link has been reported as broken. "
strBody = strBody & "Please verify before deleting." & Chr(10)
strBody = strBody & "Category: " & RecResource.Category & Chr(10)
strBody = strBody & "Title: " & RecResource.Title & Chr(10)
strBody = strBody & "URL: " & RecResource.URL & Chr(10)

where the GetDataByResourceID(sID) method returns a single row. I get the following error on the core line in bold:

Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error:

Line 124: strBody = "The following link has been reported as broken. "
Line 125: strBody = strBody & "Please verify before deleting." & Chr(10)
Line 126: strBody = strBody & "Category: " & RecResource.Category & Chr(10)
Line 127: strBody = strBody & "Title: " & RecResource.Title & Chr(10)
Line 128: strBody = strBody & "URL: " & RecResource.URL & Chr(10)

What am I doing wrong?

Diane

Resources.ResourcesRow is nothing (null).

That is why you are getting the error.

|||

You never assign a value to RecResources that is why you are getting the error. Try something like this

Dim dF As Data.DataTable = ResourceAdapter.GetDataByResourceID(sID)
Dim RecResource As Resources.ResourcesRow = dF.Rows(0)|||

That makes sense, thank you. That fixed it.

Diane

sql

Monday, February 27, 2012

Handling provider-level errors from .Net SqlClient Data Provider

Hi,

After reading this helpful blog entry:

http://blogs.msdn.com/sql_protocols/archive/2007/05/13/sql-network-interfaces-error-26-error-locating-server-instance-specified.aspx

I think this might be a good place to ask the following question.

I am writing the error handling code for my data access layer for a web application. I am using the Enterprise Library Data Access Application Block. Although this supports generic database connections, I realized that I need to handle errors specific to each database type. Microsoft SQL is the only database type I am using for now, so I am using a try...catch (SqlException e).

In testing my code, I intentionally changed the instance name in web.config to a name that does not exist. I get the very popular error 26 - Error Locating Server/Instance Specified. This is returned as a SqlException, but the SqlError.Number property is set to -1.

    Am I getting "-1" because the provider hasn't actually connected to SQL yet, so it doesn't have an actual SQL error number? Can I assume that (SqlError.Number == -1) is always a fatal, provider-level connection exception? Will the provider ever use another SqlError.Number of its own? Or do all numbers besides -1 come from the SQL sysmessages table?. Is there a comprehensive list of what exceptions might be raised by the SqlClient provider, including #26?

The reason for all the questions is that in a web application, I want to prevent the end-user from seeing the "real" exception if it has to do with configuration errors. However, maybe there are other errors that the user should see and handle? It's hard to know without a full list of SqlClient provider errors, along with the SqlError.Number that each error maps to.

Thanks and regards,

Mark

I can only answer 1. SqlError.Number corresponds to the SQL Server message id from sys.messages table on the server, so if it is not -1 it indicates an error message coming from the server.

I believe it will be impossible to get an exhaustive list of errors numbers for each error on the server. There will always be newer error messages with new SQL Servers and they number in thousands, check out the sys.messages table on SQL Server 2005.

Thanks

Waseem

|||

Waseem Basheer - MSFT wrote:

I believe it will be impossible to get an exhaustive list of errors numbers for each error on the server. There will always be newer error messages with new SQL Servers and they number in thousands, check out the sys.messages table on SQL Server 2005.

Thanks Waseem. I'm familiar with sysmessages. For messages coming directly from SQL server, sysmessages is all I need.

I am looking for a comprehensive list of SqlClient messages that are NOT in sysmessages, i.e. the errors that are raised directly by the .NET SqlClient provider. Hopefully this is a much more limited number of messages.

Regards,

Mark

|||

Hi, mcbsys

Your question is more specific to .NET Data access, so, I recommend you post your question to the forum where many experts can help you quickly.

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=45&SiteID=1

HTH

Ming.

|||

MING LV wrote:

Your question is more specific to .NET Data access, so, I recommend you post your question to the forum where many experts can help you quickly.

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=45&SiteID=1

Good idea, I will try that.

Thanks,

Mark

Sunday, February 19, 2012

Hack to Prevent Report From Running Automatically

After reading tons of articles about how to prevent initial execution
of a report (which I do know is by design), I came up with my own
hack. WARNING: This is definatey a Hack!, but once you have gotten
past the initial shock it does work quite well. (The code was only
tested on SQLRS 2005, so it may need tinkering for other versions)
Basically, from what I can gather the only way to prevent a report
from running automatically is to have a parameter whose default value
is null but required, for instance a string parameter whose Default
Value has been set to Null, with the Allow Blank Values option
checked, and the Allow Null Values option unchecked.
This works fine, if you have a paramater like this already that you
can just set the default value to Null, but if you don't want a Null
default value then you are out of luck.
You could create an additional parameter just for the sake of
preventing the report from running, but this mucks up the interface,
and having to tell your users, to just ignore that one parameter, it's
only there to keep the report from running straight-away is pretty
rubbish.
But following on that logic, you could create one of these extra
"ghost parameters" and then hide it from view when the page is loaded,
giving you the functionality of the above scenario, but without the
ugly textbox hanging around. This is quite different from creating a
"hidden parameter" by selecting the hidden radio button on the
parameter edit screen in reporting services which for a number of
reasons cannot be used to keep to the report from running.
So to implement it depends on where you are running the report from,
if you are using the Report Manager, the nice little out-of-the-box MS
tool for viewing the reports, then you need only need to modify the C:
\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services
\ReportManager\Pages\Report.aspx file
or wherever your SQL server reporting services install is located to
look like the following:
<%@. Register TagPrefix="MSRS"
Namespace="Microsoft.ReportingServices.UI"
Assembly="ReportingServicesWebUserInterface" %>
<%@. Page language="c#" Codebehind="Report.aspx.cs"
AutoEventWireup="true"
Inherits="Microsoft.ReportingServices.UI.ReportWrapperPage"
EnableEventValidation="false" %>
<script language="C#" runat="server">
void Page_Load(object sender, EventArgs e) {
string ScriptText = "<script language='javascript'>" +
"var x =document.getElementsByTagName('span'); " +
"for (i=0;i<x.length;i++) " +
"{ " +
"if (x[i].innerText == 'ghostparam') { " +
"var node = x[i].parentElement; " +
"if (node) " +
"node.style.visibility = 'hidden'; " +
"node = node.nextSibling; " +
"if (node) " +
"node.style.visibility = 'hidden'; " +
"} " +
"}";
ScriptText += "<" + (char)47 + "script>";
Page.RegisterStartupScript("hackit",ScriptText);
}
</script>
Note the AutoEventWireup="true" in the Page Directive has been
changed, it is set to "false" by default.
If however you are calling the Web Service directly and not from the
Report Manager and embedding it in your app the change is even easier,
just edit the C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting
Services\ReportServer\Pages\ReportViewer.aspx file and add the
following javascript directly just after the closing </form> tag.
<script language="javascript">
var x =document.getElementsByTagName("span");
for (i=0;i<x.length;i++)
{
if (x[i].innerText == "ghostparam") {
var node = x[i].parentElement;
if (node)
node.style.visibility = "hidden";
node = node.nextSibling;
if (node)
node.style.visibility = "hidden";
}
}
</script>
There may be a better way to write this javascript, and of course it
WILL BREAK if microsoft changes the way they output the html in a
future version of Reporting Services, so you will have to modify it
accordingly,
but any modifications should be straightforward and simple just find
the ghostparam textbox in the html and hide it.
The javascript examples above do rely on you creating a textbox
parameter called "ghostparam" with a Default Value of Null, and Allow
Nulls Values set to False and Allow Blanks Set to True. The absence
of such a parameter will not cause an error, it just means unless
there is another parameter preventing it, the report will just run
automatically as usual.
This should help a few of the more "liberal developers" out there :)
AlOn Feb 26, 11:13 am, o2sim...@.gmail.com wrote:
> After reading tons of articles about how topreventinitial execution
> of a report (which I do know is by design), I came up with my own
> hack. WARNING: This is definatey a Hack!, but once you have gotten
> past the initial shock it does work quite well. (The code was only
> tested on SQLRS 2005, so it may need tinkering for other versions)
> Basically, from what I can gather the only way topreventa report
> from running automatically is to have a parameter whose default value
> is null but required, for instance a string parameter whose Default
> Value has been set to Null, with the Allow Blank Values option
> checked, and the Allow Null Values option unchecked.
> This works fine, if you have a paramater like this already that you
> can just set the default value to Null, but if you don't want a Null
> default value then you are out of luck.
> You could create an additional parameter just for the sake of
> preventing the report from running, but this mucks up the interface,
> and having to tell your users, to just ignore that one parameter, it's
> only there to keep the report from running straight-away is pretty
> rubbish.
> But following on that logic, you could create one of these extra
> "ghost parameters" and then hide it from view when the page is loaded,
> giving you the functionality of the above scenario, but without the
> ugly textbox hanging around. This is quite different from creating a
> "hidden parameter" by selecting the hidden radio button on the
> parameter edit screen inreportingserviceswhich for a number of
> reasons cannot be used to keep to the report from running.
> So to implement it depends on where you are running the report from,
> if you are using the Report Manager, the nice little out-of-the-box MS
> tool for viewing the reports, then you need only need to modify the C:
> \Program Files\Microsoft SQL Server\MSSQL.2\ReportingServices
> \ReportManager\Pages\Report.aspx file
> or wherever your SQL serverreportingservicesinstall is located to
> look like the following:
> <%@. Register TagPrefix="MSRS"
> Namespace="Microsoft.ReportingServices.UI"
> Assembly="ReportingServicesWebUserInterface" %>
> <%@. Page language="c#" Codebehind="Report.aspx.cs"
> AutoEventWireup="true"
> Inherits="Microsoft.ReportingServices.UI.ReportWrapperPage"
> EnableEventValidation="false" %>
> <script language="C#" runat="server">
> void Page_Load(object sender, EventArgs e) {
> string ScriptText => "<script language='javascript'>" +
> "var x =document.getElementsByTagName('span'); " +
> "for (i=0;i<x.length;i++) " +
> "{ " +
> "if (x[i].innerText == 'ghostparam') { " +
> "var node = x[i].parentElement; " +
> "if (node) " +
> "node.style.visibility = 'hidden'; " +
> "node = node.nextSibling; " +
> "if (node) " +
> "node.style.visibility = 'hidden'; " +
> "} " +
> "}";
> ScriptText += "<" + (char)47 + "script>";
> Page.RegisterStartupScript("hackit",ScriptText);
> }
> </script>
> Note the AutoEventWireup="true" in the Page Directive has been
> changed, it is set to "false" by default.
> If however you are calling the Web Service directly and not from the
> Report Manager and embedding it in your app the change is even easier,
> just edit the C:\Program Files\Microsoft SQL Server\MSSQL.2\ReportingServices\ReportServer\Pages\ReportViewer.aspx file and add the
> following javascript directly just after the closing </form> tag.
> <script language="javascript">
> var x =document.getElementsByTagName("span");
> for (i=0;i<x.length;i++)
> {
> if (x[i].innerText == "ghostparam") {
> var node = x[i].parentElement;
> if (node)
> node.style.visibility = "hidden";
> node = node.nextSibling;
> if (node)
> node.style.visibility = "hidden";
> }
> }
> </script>
> There may be a better way to write this javascript, and of course it
> WILL BREAK if microsoft changes the way they output the html in a
> future version ofReportingServices, so you will have to modify it
> accordingly,
> but any modifications should be straightforward and simple just find
> the ghostparam textbox in the html and hide it.
> The javascript examples above do rely on you creating a textbox
> parameter called "ghostparam" with a Default Value of Null, and Allow
> Nulls Values set to False and Allow Blanks Set to True. The absence
> of such a parameter will not cause an error, it just means unless
> there is another parameter preventing it, the report will just run
> automatically as usual.
> This should help a few of the more "liberal developers" out there :)
> Al
Thanks for sharing this hack Al, it works great!
Oleksiy|||Hi,
Thanks for the hack. In addition to prevent report from running automatically, It helped me in placing the parameters order. I had 3 parameters and the last 2 parameters I wanted in a line & the hack helped me. Great stuff
From http://www.developmentnow.com/g/115_2007_2_0_0_937186/Hack-to-Prevent-Report-From-Running-Automatically.ht
Posted via DevelopmentNow.com Group
http://www.developmentnow.com